A formal change control process is used to manage updates and changes in many corporate environments. In this video, you’ll learn about change control, rollback procedures, risk analysis, end-user acceptance, and more.
If you’re making a change to a computer at home, you don’t have to ask anyone for permission. You simply press the Update button and your system is made that change. But in a larger organization, you have to be very careful about making a change because one minor modification can have a dramatic impact on all of your systems. This applies to any type of change. This could be upgrading a piece of software or patching an application to fix a bug, or it may involve making a change to a firewall or switch port.
This could be a significant risk for the enterprise because one single change could have a dramatic effect on your organization’s ability to do business. And you’ll find some companies where a change management process is well ingrained within the organization’s processes and procedures. But you will occasionally run across an organization that doesn’t have any type of change control that can certainly be a recipe for disaster.
A formal change control process will provide very clear documentation and policies on how changes should be implemented in the organization. And if an organization doesn’t currently have a change control process, this can be very difficult to implement into an organization that previously had no checks and balances at all. One of the most important parts of any change control process is the ability to go back to a previous configuration.
This is a rollback plan, and it should be a well documented process on how you can implement a change, and if that change doesn’t work, to go back to the original configuration. This is always not as easy as turning a switch and everything goes back the way it was. Sometimes this is a very involved process to implement the change, and just as involved to revert back to the previous configuration.
But if you’re someone very familiar with the change control process, then you know how important these rollback plans are, and you’ve probably taken plenty of backups so that you can always revert back to the previous config. There are many different uses of the term sandbox in information technology. And in this particular context, we’re referring to sandbox in the world of application development.
If you’re writing an application or need to be able to test that application, you would probably do that from an environment that will not have any impact on the rest of the organization. We often refer to this as a sandbox because you can make changes, perform tests, and try different things without any worry of affecting the production systems. This is perfect for doing tests before deploying something into a production environment.
You can put it in a sandbox that mirrors the same configuration as production, which means you can perform bug fixes, test those bug fixes, and then confirm the application is performing as expected. This might also be a good place to test the rollback plan. So once you implement the patch into the sandbox, you can try reverting to the previous configuration just to make sure the process is one that works properly just in case you have to use that during the actual change control process.
We often talk about the change control process as if IT is the only part of the organization that has anything to do with change control. But in reality, the entire organization is involved with the change control process. This often starts with the information technology team because they are the ones performing the actual change. And anything dealing with software or systems will certainly be the responsibility of information technology.
But of course IT doesn’t often exist just to support IT. There’s usually a part of the business that is using this application that needs the upgrade or the change to be implemented. We often refer to this user of the software or hardware as the business customer. They’re the ones that are using the application and need this change to occur, and they’re relying on IT to implement the change on their behalf.
Overseeing all of this is usually an organization sponsor. This is a part of the company that is responsible financially for making this change. They will be the ones that are either paying for the change to occur, or they’ll be the ones to profit from the change once it’s implemented. The change control process is a very formal and well defined process that must be followed for every change that occurs in the organization.
By following these steps, you can avoid or minimize the amount of downtime associated with the change, avoid any confusion that may occur between different parts of the organization, and in some cases, avoid making mistakes because the right people weren’t informed. This is a multi step process that usually starts with someone needing to make a change and filling out a form detailing what that change is going to be.
This usually involves defining the scope of this change and the date and time this change is scheduled to occur. There’s usually documentation that shows all of the systems that we’ll be affected by this change, and what risk there is in making the change to these systems. We would then get approval from the change control board to proceed with that update. And then once the update is complete, we would get in user acceptance that confirms that the update is working as expected.
As you can probably already tell, this process is very heavy with documentation. We usually submit this change control request to the 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.
This list of proposed changes is usually one that’s available for anyone to look through, not just the change control board. This allows every part of the organization to understand what changes may be proposed and what changes may be affecting their systems. 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.
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. 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.
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.
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.
Once you provide all of this 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.
And one of the last steps of the change control process is having the end users confirm that the change was successful. This end user acceptance is 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.
The key to any change control process is this line of communication. If you have everyone involved in this process from the very beginning and the lines of communication are open, then you’ll have a very successful change control process.