How to capture and handle change requests

This article will discuss how to capture change requests and what to do with them.

 

A change request is an important component of the change management process. It details what change needs to made to a system, excluding how the change should be made. Change requests created are usually in response to:

1. Problems with the system, known as bugs.
2. System enhancements, or improvements to the system
3. In reaction to changes to other parts of the system
4. Demands from senior management or business teams.

Change requests result in the following, when incorrectly handled:

1. Homegrown workarounds are created
2. Unapproved business processes changes are made
3. Customer service is diminished
4. Team morale and confidence in the software drops

What happens to teams who cannot handle change requests?

When change requests are not correctly handled, a few things simultaneously happen to different parts of the organisation. Let’s have a look.

End users

Internal users and employees are extremely useful in helping to align business processes with application development. This is because they are the closest to linking both technology with business process. The development team understands the technology, the management/business team understand the business processes. But only the end users link both technology with business. When management and development teams ignore change requests, users will create manual workarounds. This devalues business intelligence and makes training new staff difficult, among other things. How many excel spreads with nested marcos exist in your workplace? Created by that ‘guy’ who knew how to program ‘a little’, and has since left the company. Allowing users to voice their opinions is very important.  

Customers (general public or clients)

You generally only hear from these stakeholders if they are paying for a service and using it directly. Feedback for change from this type of stakeholder can often be the best or most well addressed. As support teams must provide help, else they risk losing a paying customer. Having an easy method of contacting support teams and a streamlined support process is paramount to maximise quality change management.

Development team

Often the development team (programmers, testers or business analysts) are not intimately connected to end users and business processes. Their sole focus is usually system architecture and code. Without proper review processes for change requests, programmers will find themselves deleting code or recoding changes to the same component. The development team know structurally what works best for a good return on investment. These stakeholders should be involved early when assessing change requests. 

Management

The biggest issue for the management team is cost and seeing results. Management need to be the drivers of strategy which leads the focus of change. They need good advice from ground level staff to understand what the details of the of overall issues are. In order to help make good decisions on where to focus resources.

Requesters and how they request

In an ideal world, an organisation would accept all comments and issues relating to how an application is functioning and address them courteously and in a timely manner. Additionally, these change requests would be written using a common template and be easily interpreted by all impacted parties. Most organisations don’t have the resources to provide this kind of service. So we need to come up with a sustainable model of thinking, that doesn’t ignore users of the applications we build and maintain.

Who should be able to make requests for change?

Everyone should be able to submit a change request. Many hands make light work. However, the rationale and submission should come from one person or role. This ideally should be the Product Owner. Other roles that could fulfil this responsibility, could be Subject Matter Experts, Product Managers or Business Analysts. The Product Owner should be connected to the users of their application or component of the application they are responsible for. It is their responsibility to know how to connect with and communicate with their users/stakeholders. Requests should come directly from them, to the development team or IT support service.

Gathering thoughts, feelings and issues from users is difficult. Think of a company or application, that when something goes wrong you can get the issue solved quickly and easily. This is a company that has good engagement with users, emulate what they are doing well.

Categorise change requests

Issues that have been raised are usually categorised in two ways, as bugs or enhancements. Bugs usually have a higher priority, so need to follow a different channel when addressing the issue, opposed to enhancements. It will depend on the urgency and the overall company strategy to determine which is treated with more importance. Another approach is to have a support team solely address bugs and a development/project team handle the enhancements. But to coordinate release schedules all change needs to be directed through a central authority, usually a Project Management Office. To be clear, both types of change need to go through the same change management process.

What to do with change requests once you have them

Once you have a list of change requests you will then need to follow this process to curate them and have them ready to be worked on.

1. Assess
   Assess whether the issue is actually a problem or not. It might be a matter of training. If it is a change that needs to be considered, then begin by writing a description. The management and development teams should be able to easily understand it. Set a temporary priority rating (P1, P2 or P3 for bugs) and possibly a due date.
2. Team review
   As a team, have the correct stakeholders present to discuss the issue. You can do this using the Planning Poker method, but essentially you need to answer the following questions:
   – Is it a bug or an enhancement?
   – What is it’s priority?
   In comparison to the overall company strategy and in comparison to other planned work. To simplify things, start by prioritising from 1-10, don’t use low/med/high, it rarely works.
   – How long will it take to complete?
   This is where Planning Poker can be useful. Who does the change impact? The analyst assessing the change in step one, should have already answered this question.
   
3. Create a backlog and release schedule
   From the review session, you should now be able to create a work schedule and a release schedule. But it’s important to have the issues you can’t work on in a backlog. Don’t leave this backlog to collect dust, regularly groom the it and have a limit of how many issues you store in it. Else, you will become overwhelmed with the amount of work your team has. Schedule your release according to your priority and available resources. How best to schedule and think about your release is a topic I will address in a separate article.

Summary