Companies have long understood the need for project management; but project based business analysis has always been an open item for discussion and displacement. Businesses are beginning to see the value in having the expertise that a business analyst can bring to a project. However, these same organizations continue to struggle with determining the appropriate area of the company that will serve as the best fit for the business analyst (BA) role, in part due to a misunderstanding of the differences between a business unit focused business analyst (BFBA) and a technical systems area business analyst (ITBA).
Business Analysis from the Business Unit Perspective
The business unit focused business analyst (BFBA) needs to understand the project from the business standpoint. The BFBA role may produce the Project Agreement, and other forms of documentation, but their primary role is the creation and documentation of the business requirements, and current and future-state business process workflows.
In order to understand the complete scope of the project, the BFBA’s first task is to ensure that the correct individuals from all affected departments are included as part of the project team for business process workflow and requirements gathering. Once all the affected parties are involved, the BFBA can begin the process of determining the current-state business process workflow. Once that task is completed, and approved, the BFBA documents the future-state business workflow. Following approval of the workflows, the BFBA performs a gap analysis to clarify the project scope and to serve as the focal point for requirements gathering. These gaps do not always affect the IT systems.
The BAFA will use the findings from the gap analysis and businesses process re-engineering flows, to start the business requirements gathering process. The business requirements will contain anything that affects the project from the business side. This will include, but not be limited to, IT system changes. Items such as report distribution, workflow, etc., will be contained in the requirements document.
This means the BFBA role must work with the business operations and technical systems areas to ensure that both the functional and non-functional business needs are captured in the business requirements. This is where the BFBA role can get confusing. The BFBA will capture the non-functional requirements from the business perspective. For example, the business requirement might read; “If a user enters the wrong USERID or password, the system will return a logon error to the user.” The system/functional requirements will explore this business requirement from a detailed system standpoint, and how this request affects the infrastructure, impacted interfaces, data warehousing and job processes.
To ensure that the system impacts are captured during the business requirements gathering process, an IT representative, in the role of an observer, should be involved in the requirements gathering process.
Once the business requirements are complete and fully approved, the document is handed-off to the technical systems area (IT), to document the project impacts to the system.
The BFBA will stay engaged throughout the entire project lifecycle to assist with requirements clarification, change management analysis, and review of testing material and training material development.
Business Analysis from the Technical Systems Area Perspective
The IT business analyst (ITBA) serves as a system analyst and/or functional analyst. The ITBA role is generally more ‘technical’ and must be able to clearly identify and define the non-functional aspects of the requested system change. This means that the role becomes less attuned to the business needs and more focused on the system impact and design of the requested business changes. Some of the duties of an ITBA may include the following:• Prototyping• System Design• Use case preparation • System modeling• Documenting the system functional and infrastructure aspects of the business requirements
The ITBA role is not a primary member of the business team defining the business requirements, business workflow or the gap analysis. However, the role should have all of the information gathered, and approved, in the business requirements process.
Once the approved business requirements are handed over to the IT area, the ITBA can begin the process of documenting the system/functional impacts. The ITBA will capture the detailed system requirements, which must include all impacted IT areas, into the final system/functional requirements document. Only those requirements that will affect a direct change/addition/deletion to the current system processing and/or functionality, including vendors, will be captured in the system/functional requirements.
The ITBA will be engaged in the project life cycle to develop and document the system/functional requirements, and assists with requirements clarification during technical design and development. The ITBA manages the requirements traceability matrix from development through testing and assists in the development of the testing strategy and test case preparation and review.
Conclusion
The BFBA needs to understand how the business operates and how to construct a business process workflow and business gap analysis. The ITBA role needs to have a strong understanding of the technical side of systems, including hardware, infrastructure, software and more.
While there are business analysts experienced in both aspects of the BA role, from the system (ITBA) and business (BFBA) standpoints, if one person tries to fulfill both roles (ITBA and BFBA), at the same time, they will be hard-pressed to effectively shift their focus between the potentially conflicting needs of the business and the systems while capturing the requirements.
The model with one person in the BFBA role, developing business requirements, reporting the business or project management office, and a separate person in the ITBA role developing functional/system-focused requirements, reporting to IT, represents one of the smoothest, and quickest, transitions, for moving a project from initiation to system design. In addition, having this distinct differentiation gives everyone in the company a better understanding of what will be delivered, by what area (IT or business), along with an understanding of the BFBA role and ITBA roles.
