A Business Analyst's Guide To Managing Change Requests

Depositphotos_16179343_m-2015.jpg

It’s common knowledge that people tend to resist change as much as they can. However, without change, there can’t be progress and BAs would certainly not have that much to do. When working on large projects, change requests from stakeholders are to be expected. Successful project managers and analysts know how to manage them without bringing the project to a standstill.

Some of the most successful software implementations I've seen in recent times have only become so because of the business' flexibility to absorb changes within the limits of existing resources over time. Successful change request implementations create more efficient systems that are able to meet the current needs of the business consistently.

Changes Happen—Deal With It

A change request may have far-reaching consequences, negatively affecting the morale of the entire team. When clients suddenly decide to alter an implemented feature, it can feel like a significant step back or that your team didn't get things right in the first place. It’s important to realize and internalize that changes can happen at any point in the life cycle of a solution, and it's not always because the BA was too incompetent to spot the requirement early enough. 

Bearing in mind that changes are inevitable and it’s only a matter of time for them to happen, the best strategy is to plan ahead and be ready when they knock on the door. A well-thought-out strategy for receiving and processing change requests is often the difference between a project completed on time and budget and a project completed late and over budget. 

Though change management is often considered as central to a Project Manager’s portfolio, business analysts are also called upon when it’s time to assess a change, determine its feasibility and prepare specifications for its implementation. In some cases, change requests are identified by stakeholders during the course of interacting with the business analyst. It is therefore important for BAs to familiarize themselves with the change request process and stick to predefined procedures of how they should be managed.

Change Request Workflow

What follows is an example of a change request workflow with tips and suggestions on how to best handle change requests.

1. Receiving a change request

Change requests have countless different forms, from brief requests in the form of an email to lengthy requests filed in a conference room. In all cases, the form isn’t nearly as important as the content. The goal, at this stage, is to capture as many details as possible and verify that the request has been captured in its entirety. If the request sounds too outlandish even without in-depth analysis, don’t be afraid to voice your opinion and nip it in the bud. All change requests should ideally be reviewed by a senior authority to be considered valid.

2. Conducting a preliminary change assessment

A preliminary change assessment should analyze the impact the change request is likely to have on the project schedule, budget, resources, scope, and other existing systems, just to name a few areas of assessment. The purpose of a preliminary change request assessment is to find out the effects of the change. Some changes have such a large impact and so little value that they are not worth implementing at any stage, especially near project completion. Part of assessing the change involves identifying and evaluating alternatives for meeting stakeholders' requirements.

3. Assessing the priority of the change request

Some change requests should be dealt with without any delays, while other change requests can wait virtually indefinitely. It’s important to clearly separate various kinds of change requests and deal with them according to their priorities. This will ensure that the team is not overwhelmed unnecessarily. Having a Change Control Board, comprising senior executives, that reviews change requests can go a long way in ensuring that only requests with clear business benefits are approved.

4. Taking action

Once you know which change requests to implement and which to disregard, it’s time to take action. At this stage, it’s paramount to resist working on low-priority change requests before dealing with urgent change requests.

5. Providing feedback

Regardless of whether you’ve decided to dismiss or implement a change, you need to inform the customer of its status. In some cases, this could lead to additional change requests, but you can easily deal with them using the same workflow. 

What's your experience with change requests?