Change Management During Maintenance

System administrators (or indeed anyone responsible for system maintenance**) are a nexus of communication, reaching out to many stakeholders representing both customers and developers.

It’s common for these different stakeholders to have very divergent opinions on how to prioritize changes to the system. After all, the administrator’s mandate from the system owner is to ensure that the system functionality, reliability, availability, and performance all remain high, while keeping costs in check.

Balancing these priorities – and the occasional trade-offs between them – makes system maintenance challenging. Since there’s no such thing as infinite resources, whoever is responsible for maintenance has to rationally prioritize change requests, while keeping healthy relationships with all stakeholders – even those who don’t get their demands met in this particular release.

In essence, Change Management is already hard, but with all the different people and toes to tread on, it only gets harder.

So, how do you decide who you should listen to? The stakeholders who shout the loudest or whoever is shelling out money for your budget?

Having to choose only one option is never ideal, so you have to weigh multiple factors and implement a structured way to prioritize change requests.

The best way to minimize friction is to communicate the process early and often: from the point a change request is submitted a decision is made about how to act on it, everyone in the organization should know how their needs will be evaluated. The process also has to accommodate changes that might affect other systems. A common solution is to use a CCB (Change Control Board) where a group of informed stakeholders makes decisions on which changes will be implemented and which will not.

How is my Change Management faring now?

A clear sign that your change management process is working is a lack of fire drills. Frequent emergency fixes stress out developers and users alike, and since it’s hard to make urgent changes in a structured manner, you will actually undermine the integrity of your system over time. You might even run out of time for important activities like testing.

Routines for change management

Your organization can handle system changes in many different ways. A common approach is that changes start with a user’s problem or change request. The user contacts a system administrator or help desk, who in turn creates a new task. The task is sent to the system administrator, and if the problem is urgent, the administrator will manage it directly with the system provider or an internal developer.

Less-urgent cases are put into a stack to be reviewed by the Change Control Board (CCB) when it starts planning the next version of the system. A developer implements the change and reports back to the system administrator, who tests the fix with one or more end users.

Managing changes iteratively

All system maintenance should be carried out iteratively.

 

Every iteration begins with a requirements management phase, where you go through items carried over from previous iterations, document new requirements, gather additional requirements, prioritize requirements, and decide what to tackle in the iteration. Then you design the system, implement changes in the code, and test the system on various testing levels.

When the iteration is complete, you start the next one. Each iteration usually takes 3-12 weeks (although the ideal is no more than 4 weeks). If the changes are large or numerous, you can divide them up into several iterations, of which only the final iteration ends in deployment. This will help you achieve higher levels of quality, because you test every change several times. It also avoids so-called “big-bang” deliveries in which a huge amount of functionality is delivered in the final week of the process.

By working iteratively, you handle the most important requirements first, but that doesn’t mean you overlook less-important requirements. Stakeholders should be aware that even “smaller, less-important” requirements are an important part of the process, and not shoved under the rug. The key to making it work is ensuring that stakeholders know that there is a process, and that it covers every requirement through multiple iterations.

 

Activities during requirements management

Stakeholder Analysis

If you’re running in the wrong direction, it doesn’t matter how fast you get there. And if you’re listening to the wrong stakeholders, it doesn’t matter how well you’ve documented their requirements.

Over the course of any system’s lifetime, the environment around the system changes, so it’s a good idea to periodically conduct a stakeholder analysis. I recommend you carry out a stakeholder analysis at least once a year throughout the maintenance phase.

Just like in development, working iteratively is an effective way to do the analysis. You start in the first iteration by listing every stakeholder you can think of. Then define what each stakeholder wants from system maintenance and/or what system maintenance wants from the stakeholder.

Finally, go through the list one last time to find any gaps you might have missed. Your list will be much more complete if you develop it iteratively than if you try to capture all the information the first time around. And be sure to conduct your stakeholder analysis in a group, since input from more people will provide a more comprehensive picture than one person’s view alone.

 

Requirements Gathering Techniques

In order to gather requirements, you can utilize a host of different techniques: Workshops and interviews are two common ones. Workshops can be as simple as a group exercise putting post-its on a white board; the participants should be representative stakeholders from both the client and the provider side, while someone from system maintenance guides the process.

Workshops are an excellent technique for collecting, organizing, and prioritizing ideas of all kinds, including initial requirements and change requests, and they are especially useful when you have a surge in change requests. You don’t really need to bother using a workshop if you only have a handful of changes to deal with; in that case, it’s just as effective to interview a few stakeholders instead. The biggest benefit of workshops is that participants build on each other’s ideas, and attack problems from multiple perspectives, providing you with a lot more ideas than if you had been working in isolation or in small groups to come up with the requirements. The point of workshops is that it gives you more ideas to choose from in the next step, when you prioritize your planned actions.

Interviews offer an alternative or complement to workshops. Anyone can conduct interviews with a little training and preparation. The purpose of an interview might be to identify so-called “implied” or “expected” requirements. These are requirements that are so obvious to the clients that they sometimes don’t even think to mention them.

Unfortunately, you can’t just ask a stakeholder “what requirements are so obvious to you that you aren’t even thinking about them?” You’ll have to try other tactics and questions to extract as complete a picture as possible.

Sample interview questions:

– How many users will use this feature?

– Is there anything that the system must do or must not do? Are there any functions that it really ought to have, or that would simply be nice to have?

– Is there anything that needs to happen with some regularity or frequency?

– How and when should data be deleted from the system?

It’s not possible to capture every implicit requirement through interviews. If you’re making major changes to the user interface, you should also create prototypes and perform usability testing where you observe users trying to use the function.

Prioritizing change requests

After you’ve completed requirements gathering and analyzing the carry-over task list, you prioritize tasks based on the costs and benefits associated with each change. Several parties need to participate in the prioritization process: representatives from the client side should assess the value of the change to the business, while the IT department or system provider can assess the complexity, risk, and cost of the change. By discussing their common priorities, each will improve his understanding of the other’s views.

I recommend that you prioritize every change request based partly on cost and partly on business value. It’s a good idea to jointly arrive at what scale to use for assigning priority to tasks. If the groups contributing to the prioritization agree on the scale it is much easier to gain acceptance for the decisions about which changes should be implemented, by when. The process should be visual and clear, since that makes it easier for someone to understand why their pet requirement didn’t make the list — it’s maybe not as important from a business perspective in comparison to a different requirement that made the list. You can manage prioritization in Excel, on a whiteboard, or by using a requirements management tool such as ReQtest. Using ReQtest, you can easily identify the change requests that provide maximum business value while costing the least amount of money to implement.

Making decisions about changes in the Change Control Board (CCB)

The last step in the change management process is to decide what changes your team will implement. This is done in a Change Control Board (CCB). I recommend that every major maintenance assignment you’re on includes a CCB, and in fact CCBs are very common in project-based development. The Change Control Board is a small group of people who meet to review proposed changes, so CCB members need to possess a range of competencies, including knowledge of the business, the user perspective, and technology skills. The group should be small and empowered to make decisions; just 2-4 people is often sufficient. The core of the CCB is made up of managers from both the business and technology side, supplemented by system owners, IT managers, developers, users, etc. as needed.

Changes can be made at several levels of the organization, depending on the size and impact of the change. Smaller changes can be handled in day-to-day communication between people working on the system being maintained, while the system owner usually makes major decisions that affect the schedule, budget, resources, and quality; decisions about extremely large changes are the responsibility of the overall organization’s leadership. On each of these levels, you may find a different CCB that can assist and intervene. For example, there might be one CCB for changes at the management level, but a different one for dealing with changes that affect integration with other systems. If your organization or the system are small, the system administrator or system owner may constitute a one-person CCB, informed and empowered to make final decisions alone.

As a basis for decision-making at CCB meetings, you’ll need to provide data pulled from a requirements management tool. You can record any change-related decisions made at the meeting directly in the tool.

Summary

• The change management process must be well-known and anchored in the organization.
• By prioritizing iteratively, you deal with the most important requirements first, without forgetting about minor requirements.
• Both client and provider should participate in prioritization of changes.
• After the prioritization exercise, the CCB makes decisions about what changes to implement and when.

** While system administrators are formally responsible for keeping an IT system up and running, people with other roles often contribute to or lead activities such as those described in this article. For simplicity’s sake, we have used the term ”system administrator” but we do realize that people in a great many other roles could be responsible as well.