Do you understand the difference between the 5 categories of change and how this will impact you? Here's a brief primer.
Effective change management processes are an essential part of any IT deployment. A company's IT infrastructure is a hugely complex set of interconnected and interdependent systems, and making alterations to one system within this could have far-reaching unintended consequences if the process is not managed effectively.
Therefore, following established procedures ensures that everyone involved understands what is going on throughout the process, guarantees accountability, and reduces the risk of errors or delays derailing the project.
In order to do this, it's important to understand the different categories of change. ITIL standards set out several key definitions for IT service management professionals to follow, covering everything from everyday, low-risk to emergency situations. Here are five key categories of change within this that you'll need to be aware of.
1. Standard change
Most planned changes will be considered 'standard'. In this environment, this refers to changes that are pre-authorized and will follow an established procedure in order to meet a specific requirement. They are usually classed as relatively low-risk, and therefore are not required to follow a full, in-depth assessment or monitoring process.
Key elements that are part of a standard change include a defined trigger that initiates the request for change and approval given in advance. Because this may be a fairly frequent activity, there is usually no need to log a formal request for change or obtain specific authorization, as the tasks involved will be straightforward, documented and follow tried and tested steps.
2. Normal change
At first glance, many people might wonder what the difference is between a standard and normal change. After all, don't they both mean the same thing? However, when it comes to change management, 'normal' refers to changes that are required to follow the complete formal process. As they will usually be significant changes to processes, technologies or infrastructure, they are usually (though not always) higher-risk changes than those that fall under the 'standard' category, and so will require an extra layer of scrutiny.
Normal processes will therefore begin with a formal request for change that will be reviewed by the organization's change advisory board for approval or rejection. Then, the process itself will follow all predefined steps, including assessing and evaluating the change, planning and implementation, and post-change review. All these stages must be fully documented and audited to ensure there is a complete record of everything that has occurred throughout the activity.
3. Minor change
A minor change is usually one that does not require a significant amount of preparation and planning, such as the implementation of a scheduled security patch or the installation of a new device onto the network. They are usually low-risk and won't have a large impact on how the business operates, so can be implemented using the standard process. However, that does not necessarily mean they can be treated lightly, as there may be relatively minor changes that will still need strong monitoring and auditing for reasons of compliance, or if they will impact sensitive applications or mission-critical systems.
4. Major change
Major changes will be ones that have a significant effect on the day-to-day workings of the business. It might, for example, include a significant alteration of a network's infrastructure that will require a period of downtime, or migrating from a legacy application to a newer one. These will be complex, many-stepped processes and therefore must undergo detailed preparation work before the implementation phase. The direct approval and oversight of the change advisory board will be a requirement for this, especially for actions that are classed as medium or high-risk.
5. Emergency change
These are changes that must be implemented as soon as possible - often because a critical weakness in an existing system has been found and needs to be fixed before it can cause damage. For example, one of the most common scenarios that will mandate an emergency change is the discovery of a zero-day vulnerability that exposes an organization to hackers.
Because of this, there won't be time to go through the formal change advisory board approval process. Indeed, in some cases, anything more than a quick meeting may be a luxury the business can't afford. However, that does not mean established procedures should be ignored. There must still be a high level of authorization and oversight from a change manager and critical testing processes wherever possible.
Because emergency changes will, even with the best contingency planning, be less formalized than standard and normal changes, it's important they are only used when absolutely necessary, and not as a shortcut to avoid bureaucracy for changes that do not typically justify emergency procedures.
Insights for Professionals provide free access to the latest thought leadership from global brands. We deliver subscriber value by creating and gathering specialist content for senior professionals. To view more IT content, click here.