Steps of the Change Management Process

Request Forms - Contains the documentation necessary to begin the change management process. It is typically submitted to the change control board on an online system that allows us to document everything we’re going to do during the change control process. This also allows the change control board to see all of the requests that are pending and be able to triage or determine which process occurs first, second, third, and so on.

Purpose of Change - We usually don’t make changes just for change’s sake. We need to have some particular reason that this change will be implemented. This might be a bug fix or an application improvement and in some cases, an upgrade to an application version, or this might be a security patch that closes a vulnerability that exists on one of our servers. Every upgrade made in an organization has some cost associated with it, whether that’s an equipment cost or an employee cost. Either way, we need to make sure that the changes we’re implementing are the ones that make the most sense for the organization.

Scope of Change - By creating and sharing a working definition and scope for change management, you will be able to work more effectively with others in your organization to successfully implement changes. For example, if we’re upgrading a piece of software, this might only affect a single server in the organization. But if we’re upgrading the software on a router, this could affect many different networks and cause outages or downtime for this maintenance period.

Date and Time of Change - A part of the documentation process, here we determine the date and time this change is scheduled to occur. For example, changing a single firewall or router configuration could affect every application running in the organization and connectivity to and from any of our remote locations. This scope should also consider how long it takes to implement this change. This could be something that takes a matter of minutes or could take a number of hours. And during this time frame, the network may still be available or there may be complete outages while this change is taking place. Understanding the scope of any particular change can help you understand when this change might be implemented, and whether you may want to schedule it at a different time or date.

Determine the Affected Systems/Impact - A part of the documentation process, here we define which systems will be affected by the change as well as determine what the impact of the change will be on these systems.

Risk Analysis - We then have to associate a risk associated with the change that we want to make. This might have low risk or it may be very risky to be able to make this change. This may be a relatively low risk. so you might be adding a patch to a piece of software and if that patch doesn’t work it’s only going to affect that single software on that server. Or the process of implementing a patch to an operating system may affect all applications that are running on that server. You might be creating changes to an operating system that causes the OS to no longer properly load. Or it may corrupt data that’s on that system. All of these risks should be considered when you’re putting together the change control plan. Of course, there’s also a risk if you don’t make this change. There could be security software, and your system is vulnerable until that software is installed. So if you don’t install the software, you’re going to have to deal with that risk until the patch is applied.

Change Board Approvals - Once you provide all of the information to the change control board, they can then decide whether that change should be implemented. This board usually consists of individuals from different parts of the organization that have a different requirement for access to their data and their applications. And working together, they can all understand what the risks might be for implementing that change and understand the priorities that are associated with that group. For example, if you’re making a change to fix a critical problem with an application used by everyone in the organization, it might have a higher priority than upgrading an operating system on a single laptop. Once you receive this approval, the administrative part of the change control process is over, and now you have to actually implement the change.

End-User Acceptance - The final sign that verifies that the change was successful. For this reason, the end users have been involved throughout this change control process. They were involved with the planning for the change. They were able to evaluate the change once it occurred. And once they performed their testing and are pleased with the change, they can tell you that the change was indeed successful