When it comes to requirement changes, product managers usually try to avoid putting themselves in a dilemma between the development team and product stakeholders. From a product development perspective, changing requirements inevitably leads to the adjustment in user journey or use case, which also imposes further changes in technical infrastructure and code. As a result, more resources might be required in response to these changes, along with the extra cost incurred. From a business perspective, as the solution requirements should effectively address the business needs at a different stage and reflect stakeholders’ expectation constantly, requirements should have the flexibility to be re-captured, re-assessed and changed. Faced with the pressure exerted by both development team and key stakeholders, product managers need to work with key stakeholders to define the nature of the requirement changes, trace the connection between the changing requirements and other requirements, assess the impact of the requirement changes on the current business architecture whereas communicating the rationale of change requests with the development team, evaluate the influence of these changes on the technology infrastructure and technology capabilities in order to meet change requests.
Changing requirements can happen in a predictive or an adaptive development environment, despite the requirements are fully captured and defined to maximize control and minimize risks with the predictive method. In many cases, the change requests come through after the requirements have been approved, which are driven by changes to higher-level requirements such as business goals and these changes need to be managed appropriately for the ease of tracing and reuse in the future. Therefore, it’s essential for business analysts to establish a standard change control management process to improve the access to information and help maintain the business analysts’ accountability of the change control process.
Four Steps to Manage Change Control Process
1. Discuss the key elements of change requests with product stakeholders
Before proceeding with requirement changes, business analysts should identify the owner of procedures in the change control process in order to allocate requirement change tasks to the right person. This involves the details of steps in proposing changes, verifying changes, validating changes, communicating changes, approving and authorising changes. Once the process is determined, business analysts will need to identify key elements of change requests for the purpose of evaluating a change request. The key elements may include:
- Cost and additional resources estimate of implementing the change
- Benefit and value to explain to how the change aligns with the business objectives and adds value to the business in terms of financial and non-financial implication
- Penalty illustration to describe the situation of do nothing
- Risk analysis to predict the potential risks to initiative, stakeholders and business if implementing the change
- The course of action to present several alternative courses for decision-makers to make a choice that will best serve the needs of the initiative
2. Prioritise requirement changes
Business analysts ensure that the requirement changes are stable before prioritisation. The basis used in requirements prioritisation can be applied to prioritising requirement changes. Whilst criteria such as cost, benefit, penalty, dependencies, risk, time sensitivity, organisational readiness and regulatory or policy compliance should be taken into consideration during prioritisation, the priority of the proposed change also needs to reflect stakeholders’ interests within the current initiative.
3. Communicate requirement changes
Similar to communicating business analysis information, the business analyst provides stakeholders with the information of requirement changes in detail, which is usually presented in a package. This is to ensure stakeholders have a shared understanding of requirement changes and gain agreement on proceeding changes. Given the audience and the objective of communication, the requirement change package usually includes formal or informal documentation and presentation to explain the rationale of change initiatives, the implementation process and the evaluation of changes. Workshop, reviews and interviews are most frequently used techniques to communicate requirement changes.
4. Analyse the impact of changes and document changes for future use
Impact analysis is performed to evaluate the effect of a change on requirements, stakeholders, systems and business. Business analysts assess the impact of a proposed change request by scanning through the cost, benefit, impact, schedule and urgency. If business analysts use requirements management tools to document the changes, these changes should be allocated with absolute reference, together with the owner of the change, complexity, priority and status. These attributes help business analysis to track and trace changes easily and also can be saved for future reuse.