How BAs Fit into Projects and Development

As the business analyst (BA) role continues to evolve, the responsibilities continue to expand. One of the best ways for a business analyst to add value to a project is to understand the processes involved in both the project life cycle (PLC) and the software development life cycle (SDLC). Contrary to popular belief, the two life cycles are independent of one another, however, it's best that they are aligned. With that said, upon starting any new organization or contract, I recommend asking a reliable source for a copy of both the organization’s Project Management Office (PMO) and SDLC policies to acquire this information. The purpose of this article is to provide a high-level description of the PLC and SDLC phases and suggest key activities that the BA would perform or be involved in during those phases. The information provided is not exhaustive and can vary greatly based on the organizational structure, however, it serves to demonstrate the breadth of the business analyst role throughout the life of a project.

First, let's define the two life cycles and discuss how they relate to one another. The project life cycle provides a general framework for managing a project. According to the Project Management Institute (PMI), the project life cycle is a series of phases that a project passes through from its initiation to completion. Phases are defined as a collection of logically related project activities that close with the completion of one or more deliverables. General project phases included Initiate, Plan, Execute, Monitor and Control, and Close. The PLC phases don’t always need to start only after the completion of the prior phase. They can be overlapping and iterative as well.

A software development life cycle is a framework that defines the process used to build an application from inception to retirement. Various standard SDLC models have been established including waterfall, iterative, agile, and many others. The general, SDLC phases, however, include Planning, Analysis, Design, Implementation, Test, Deployment, and Maintenance. Like the PLC phase, the SDLC phases can overlap and be iterative. A key point is that the SDLC happens within the PLC and usually occurs during the Execution phase of the PLC. The image below illustrates the relationship between the two life cycles.

Now that we've described the life cycles, let's discuss how the business analyst role fits into these processes. Let’s start with the project life cycle.

PLC – Initiation - Defines a new project or a new phase of an existing project by obtaining authorization to start the project or phase. The business analyst may be involved in the following:

• Identify needs – Capture the business need and distinguish whether the need is a problem to solve or an opportunity to seize.
• Define goals and objectives - Help the customer define goals and SMART objectives to allow the project success to be measured. Document in the form of business requirements.
• Identify stakeholders – Generally initiated by the sponsor and project manager (PM), however, the BA can refine the list or add stakeholders when appropriate.
• Assess feasibility – Coordinate feasibility studies via a proof of concept to determine if the goals and objectives defined are possible prior to the allocation of resources.

PLC - Planning - Establishes the project, scope, refines the objectives, and defines the course of action required to reach those objectives. The business analyst would perform the following:

• Determining project approach – Collaborate with the project team to determine the project approach based on the potential risks, timelines, constraints, information known, and stability of the business requirements
• Business analysis plan – Create a business analysis approach based on the project approach. The plan will include an outline for various BA activities including stakeholder engagement and communication, requirements management, information management. This should be an input to the overall project plan.
• Assess Current State – Determine the current situation via observation, document analysis or any other method that will provide context on existing processes and systems. The BA may document this in the form of a textual current state description or present as a process model.
• Root Cause Analysis - If the business need has been identified as a problem, perform root cause analysis in order to ensure the team is trying to solve the true source of the issue. This can be executed with a Fishbone Diagram or the Five Whys method.
• Define Future State – Guide the customer to describe a definition of success, make decisions about the solution space, verify constraints, solidify business objectives, and determine the potential value. This may be documented in the form of a future state description or process model.
• Assess Risk – Discuss the unknowns and work with the project manager and sponsor to determine the risk tolerance and risk management approach.
• Perform gap analysis - Identify the difference between the current state and future state capabilities. This may be documented in the form of a process model illustrating what will change or the various transition states. This may also be represented as a change strategy.
• Prepare for elicitation – Based on the change strategy, the BA will prepare to conduct various elicitation activities in an effort to get adequate details on the requirements.
• Provide estimates – Once the BA activities are planned out, the BA may provide estimates to the PM on the work effort as an input to the project plan.

PLC - Execute - The processes and activities performed to complete the work defined in the project management plan in order to satisfy the project requirements.

• See SDLC which happens within this phase

PLC - Monitor and Control - Processes required to track, review, and regulate the progress and performance of the project; identify areas in which changes to the plan are required, and initiate the related changes.

• Control Scope – The BA plays a part in managing scope related to the solution by ensuring requirements are adequately traced and assessing requirements changes.

PLC – Close - Performed to formally complete or close a project or contract.

• Performance Measures – If customers don’t have performance metrics related to the project readily available, the business analyst may be involved in collecting and evaluating performance measures to help determine the value and success of the project.
• Lessons learned – Partake in lessons learned (retrospective) activities.

SDLC – Planning – Effort to assess the business need and determine solutions to achieve business objectives. Note that all of the objectives and proposals from the PLC are likely to be system agnostic, while the SDLC activities consider the physical systems of the solution. This planning involves a detailed feasibility study from a technical perspective regarding the resources, time, and costs to build a solution or improve an existing one. The BA may be involved in the following:

• Determine the SDLC Approach – Collaborate with the technical team to select an SDLC approach to ensure it complements the overall project approach.

SDLC – Analysis – The tasks that go into determining the needs or conditions to meet for a new or altered solution, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing solution requirements. The BA would perform the following:

• Elicit requirements: Use various methods and techniques to elicit requirements. BAs should use their judgment to select the most appropriate techniques based on the context of the situation.
• Document and Model requirements – Use various techniques to specify and model the requirements based on the PLC and SDLC approaches. Selected methods should also be based on organizational standards and should consider the intended audience and use.
• Verify and Validate requirements – Ensure requirements meet quality standards and work with stakeholders to confirm that they address the business need.
• Communicate requirements – Distribute requirements and ensure stakeholder have a shared understanding of them.

SDLC – Design – The process of envisioning and defining solutions and the required architecture to one or more sets of problems.

• Define Design Options - The business analyst should be involved in defining design options by helping to define the solution approaches, identifying improvement opportunities, and providing input in release planning. Also, the BA will ensure all design options conform to the requirements.
• Recommend a design solution – The business analyst will collaborate with the technical team in order to make a recommendation to the sponsor on which design option will add the most value based on their business insight, assessment of the situation and various other factors. The project sponsor or customer will make the ultimate decision after considering this recommendation.

SDLC – Implementation - Building a working system or solution in order to accomplish a specific project related objective. The BA would do the following:

• Support tech team – As the developers start coding, they will start reviewing the requirements much deeper and will have additional question, therefore the BA will serve as a consultant to developers and the technical teams to clarify requirements. See more on the developer/business analyst relationship here.

SDLC – Testing – An investigation conducted to provide stakeholders with information about the quality of the solution under review. It involves the execution of a solution or solution component to evaluate various criteria. The BA may be involved in the following:

• Readiness Review – The BA should review Quality Assurance (QA) and User Acceptance testing (UAT) plans to ensure they cover all possible scenarios and are aligned with the requirements. A pre-implementation readiness review is done to verify if formal testing is ready to begin.
• Defects - The business analyst can also triage QA and UAT defects to ensure viability prior to reporting to development. The BA may also assist with QA or UAT testing if either team is on a tight time-frame or short on resources.
• Training – The business analyst may facilitate user training sessions in order to prepare end user acceptance testing as well for production use.

SDLC – Deployment - Activities that make a solution available for customer use. Consists of several interrelated activities with possible transitions states between them. The BA may be involved in the following:

• Readiness review – On the night of deployment, the business analyst is likely to take part in a post-implementation readiness review in order to ensure the product is working as intended in a live environment prior to being used by the end-users.

SDLC - Maintenance - The modification of a solution after delivery in an effort to correct defects, improve performance or enhance the user experience. The BA may be involved in the following:

• Liaise – Depending on the organization structure, the BA may be the first point of contact for deployment updates and when end-users report production issues or request enhancements. In many cases, the BA will need to triage the issue in order to provide additional context to the technical team for resolution. The BA may also be the point person to report defect related status updates from the technical team to the project manager and leadership.

Hopefully, this information provides some insight on how business analysts can add value to projects and the overall organization. Sometimes it’s up to the business analyst to volunteer to be involved in these processes. Volunteering is a good way to help build relationships since everyone loves a team player!!

Author: Michael F. White, Business Analyst and Founder of The Business Analysis Doctor, LLC

Michael has an extensive background in business analysis, project management and coaching. He has driven innovation at some of the top financial institutions in the nation, holds a Doctorate in Business Administration and is also a CBAP. To learn more about The Business Analysis Doctor, LLC visit thebadoc.com