There is one thing in projects (and in life in general) that is inevitable – the change. No matter how much planning, elicitation, review and approval of requirements you perform as business analyst – always expect and be prepared for a change. In the following article from the PMI-PBA® Certification Domain series, we will focus on how to set boundaries, assess the impact and control changes to requirements, that is we will look at the different activities comprising the fourth domain Traceability and Monitoring.
So what is considered as a change? How do we know the boundaries for our project requirements? The answer to this question is one word – baseline. All approved work is inside the boundary of the baseline and everything else that is not included in the baseline needs to be approved. Once requirements are approved, these can be changed only through the change control procedures defined for the project. The format and degree of formality applied to changes varies depending on the project life cycle, project complexity, number of stakeholders and risks, and the organization’s processes for managing change. A project using waterfall methodology will likely apply a more formal and complex change control process; a less formal process is used for projects following the agile practices.
In order to explain Traceability and Monitoring domain in a more concise manner I will try to answer several questions:
What is traceability?
Simply said traceability is the tracking of product requirements from their origin to the deliverables that satisfy them.
What do we need to trace?
We should be careful with the quality and quantity of information we are tracing, or otherwise we will fall into and endless and useless loop. What we need to trace is specific for each project, but a general list is presented in the diagram below.
How can we perform tracing?
The tools that you can use to perform traceability and monitoring depend on your organizational practices and the available software. A simple method using the all time favorite tool Excel is the requirements traceability matrix. Common attributes of the matrix include:
- Requirements ID (also Requirement Parent ID) and Description
- Version, Priority, Owner
- Use Case IDs
- Reference Documents
- Class/ Method/ Function/ Procedure
- Test Case Number
Because it is hierarchical, it easily supports dependency analysis and impact analysis. As new requirements surface and existing change, these are documented, added to the traceability matrix, assessed for their impacts to the project and product, and presented to stakeholders for approval.
What is a change request, change control process, change control board?
A change request is the formal proposal for a change – as simple as this. Because we need to control the changes made to the product scope, we need an established process for this – change control process. And because we need an authorized body to review, evaluate, approve, delay, or reject changes to the project we need the change control board (quite often referred to as CCB).
How business analysis relates to change management?
Change management is of interest to both project managers and business analysts. The project manager is concerned with all things associated to project scope, while the business analyst is concerned with product scope – maintaining the integrity of the requirements and associated deliverables and to ensure that each new requirement aligns with the business need and the business and project objectives. However, both roles should work collaboratively and communicate frequently regarding the proposed changes.
In the next and last article from the PMI-PBA® Certification series we will look at the details of the last domain Evaluation – how to validate a solution or a part of it, how often to evaluate and what tools and techniques we can use so that we make sure our solution meets the business needs as expressed by stakeholders.
Find out more about:
PMI-PBA is a registered mark of the Project Management Institute, Inc.