How to handle change requests effectively

Change requests are common in any product development or services business companies. Change request is something that customers ask for after working with the product. It can be a product enhancement or a change in the workflow of the system. Change requests can be initiated by any stakeholders such as Customers, development team members, testing team members etc. In this article I'm going to talk about how change requests can be taken up effectively.

1. Understand the change: The change in the software has always an impact and cost. Hence a thorough analysis on the change and its impact has to be carried out and understood before jumping on to implement it. Sometimes it could be decided that the requested change may not even be taken up if it involves too much cost and design change.

2. Estimate time and cost: Estimating the time required to implement the change is important. The estimation decides the cost of implementing it and this is one of the challenges in handling software change requests.

3. How will the change impact the customers? : This is very essential factor to consider while implementing a change in the software product since the customers would be already trained on how to use the product and they are used to it. Its not about just implementing the change request but to consider how your end product customers are going to be impacted due to this change. A change in the workflow of the product will also involve the training the product users about the new change and updating the user guide as well.

4. Does the change have design impact?

Certain change requests might involve completely redesigning the product, so a thorough design impact analysis should be carried out before taking up the change request. When it comes to design change, it means a lot. The design change requires impact analysis on all the modules in the project. The design impact analysis helps to better estimate the cost of implementing the change request.

5. Discuss the change request with development team

Only the people who developed the product know the impacts, so its crucial to bring the change request into the consideration of development team to gather the impacted areas. It is the development team members who are going to implement the change request.


6. Project the cost and estimation of implementing the change request to your customers

Ultimately customers are the one who are going to pay for you, so discuss the cost of implementing the change request with them and more importantly get the approval from them. Categorize the cost into making code changes, updating test cases, testing effort, impacts testing effort and project the final cost of taking up the change request.

7. When to decide not to take up the change requests?

 If the change requests demands huge design changes and impacts almost every module of the project and requires the customers to re-train about the product better, decide not take up the change request. Especially when the change request adds little value to the customers but involves too much cost, convince your customers and do not even implement the change request.

8. Make it aware to all Change Control Board (CCB) members

Some organizations have change control boards who are responsible for handling the changes. Call up for a CCB meetings and discuss with them clearly about the change, its cost, estimation and get their approval to go ahead with the change.

As best practices, product bugs should not be raised as Change Requests. The CR should be valued by your customers and make end user life easier using your product. Log the change in a defect tracking tool categorizing it as a change request, many defect tracking tools have this option of logging change requests. Record all the discussion and meeting minutes in the tool against the change request, This is required for maintenance purposes in future.

By handling the change requests (CRs) effectively, we can reduce the number of test cycles. Have a look at my article on how to reduce the Software Test Cycles.