Business analysis is a topic of growing importance in the field of managing IT projects. The marketplace reflects this importance, as different project roles increasingly embrace business analysis as a technique for uncovering business needs, managing requirements, and creating effective solutions to business problems.
Despite having years, even decades of experience, many software companies still fail to understand, document, and manage their product requirements.
As business analysis is an integral part of my work as a consultant at ITCE, I will try to address the need for definition of effective business analysis practices and how to apply them to programs and projects. The series of articles will be organized systematically around the five business analysis domains identified by PMI®:
- Needs assessment,
- Elicitation and Analysis,
- Traceability and Monitoring
In each article, I will provide details about each domain. More specifically, I will describe the purpose of each domain, the activities it includes, deliverables and examples. The content is based on the recently introduced and highly respected PMI-PBA® (Project Management Institute – Professional in Business Analysis) credential. The credential demonstrates an individual’s expertise in business analysis.
In this article from the PMI-PBA® Certification series I will introduce you to the five domains as defined by PMI®.
There is a general misconception that business analysis is all about managing the requirements. The actual business analyst work may start earlier, even before the actual start of the project. The first domain, needs assessment, includes pre-project activities that are performed to examine the internal and external business environment and address either a current business problem or an opportunity. These activities may be requested by a business stakeholder, implied by specific methodology or recommended by the business analyst before the start of a project. If, along the project, there are factors impacting results, needs assessment should be revised to ensure its decisions remain valid. Needs assessment starts with identifying problem or opportunity and finishes with preparing the business case.
Once the project start is confirmed, the business analyst must create a plan of how, where and when they will perform business analysis activities. Planning is the domain where the business analyst has to define the approach for prioritizing, documenting, validating, communicating, approving, and changing requirements. He needs to create a list of the activities to be conducted and the business analysis deliverables to be produced. The output of this domain is the business analysis work plan.
Elicitation and analysis
Next, the business analyst must put all his efforts on gathering, analyzing, documenting, validating and prioritizing the requirements. This domain includes iterative work with the following tasks: further planning, preparation, and the actual elicitation of requirements from stakeholders, analyzing and documenting the results. Finally comes defining a set of requirements in sufficient detail to enable the definition and selection of the preferred solution.
Traceability and Monitoring
Once a set of requirements is approved, they are baselined and can be changed only through the change control procedures defined for the project. Traceability and monitoring domain provides the ability to track requirements from their origin to the deliverables that satisfy them. Traceability is sometimes qualified as bidirectional or forward and backward, because requirements are traced in more than one direction. Not all projects require the same amount of traceability; therefore, the specific deliverables that will be traced for the project are determined during business analysis planning. Generally, more complex projects require more traceability. A project in a heavily regulated industry or one with large number of components, interfaces, risks, and stakeholders will likely require more detailed traceability than a project without these characteristics.
This is the last domain that we will discuss, but the evaluation related activities should not be left for the end of the project and performed only once. Evaluation should be performed early and often in a project. It provides qualitative and quantitative assessment whether or not a solution or segment of it has achieved the desired business result. It also serves as input for go/no go business decisions when releasing complete solution or just part of it.
In the next article from the series I will uncover details around the needs assessment domain. I will describe why it is so important and how to effectively perform the activities it comprises.
Find out more about:
PMI-PBA is a registered mark of the Project Management Institute, Inc.