ITIL is widely considered the gold standard when it comes to IT Service Management (ITSM) best practices and some of the most successful companies in the business have been using it and its multiple iterations over the years. Though we won’t go into detail as to what ITIL is (we’ve got a Definitive ITIL Guide for those who want a complete rundown), it could be quickly defined as a set of suggestions, best practices, and different approaches of how to do ITSM.
ITIL suggests specific approaches for the most important ITSM practices. Among the many approaches of ITIL, there’s the matter of how to carry out changes in any IT infrastructure and that’s where Change Categories come into play. We’ll take a look at what these categories are, and some use cases for each one of them. But first, we need to understand what Change Management is according to ITIL.
What is Change Management according to ITIL?
ITIL defines Change as "the addition, modification or removal of any authorized, planned, or supported service or service component that could affect IT services." Therefore, Change Management is essentially a recommended process flow that allows businesses to assess, plan, and deploy certain change requests.
The main goal of Change Management is to make sure these changes do not obstruct or slow down operations that have already been put in motion. Consequently, one could think of Change Management as a clearance system that authorizes every single change record prior to its release management stage.
Change Management process rundown
Before we dive into the different Change Categories, we need to understand the inner workings of Change Management itself. The Change Management process can be divided into 6 steps that go from submission to closure and ensure that the implemented changes require little to no further revision. They are as follows.
1. Submission
The very first stage is, of course, change initiation. This boils down to creating change tickets from your service desk of choice and collecting the necessary information by way of a change form containing mandatory fields Moreover, change roles need to be put in place. This means delegating responsibilities to different stakeholders as well as how much access each one has at every stage of a change.
2. Planning
As with any IT initiative, planning is the quintessential part of any successful change implementation. Additionally, it is crucial to get the needed approvals to actually implement said change. At this stage key aspects such as rollout/backout plans, expected downtime, and impact are all conveyed to executive powers to explain why a specific change is needed in the first place.
3. Approval
As its name suggests, approval is the stage where the change plan is greenlit by the Change Advisory Board (CAB). The CAB is a combination of teams and roles in a company that can range from executives and team managers to financial staff or technical teams. Oftentimes custom CABs are created in order to swiftly manage approvals. Even automating these approvals is an option to speed up the process depending on the company and the change in question.
4. Implementation
The implementation stage is where the actual change takes place. There are two ways to go about this: there’s task creation and projects.
Task creation means assigning tasks to different technician teams to overlook and manage the work done during the implementation, while projects are broader in scope and tend to require more meticulous planning. A clear example of an implementation that requires task creation would be updating security software in a particular dependency and a project-based implementation could involve moving an entire company’s infrastructure to the cloud.
5. Review
The ironing-out stage. Any issues with the change are put under scrutiny before it is closed to ensure that the change has been deployed correctly.
6. Closure
The very last stage of the Change Management process. The change itself is labeled as successful, failed, or incomplete according to the outcome of said change. This labeling system helps organizations have more useful and precise metrics for future changes.
For more detailed information on Change Management, don’t hesitate to read our Change Management Tips. We are now ready to jump into the Change Categories themselves:
Change Categories and their use cases
Change categories can be divided into four distinct categories, all corresponding to different levels of complexity and/or scope:
Major Change
Major changes are a synonym of high risk and high impact. Their deployment needs to be efficient as these major changes run the risk of disrupting production and workflow. The scheduling of said change is decided after a major change evaluation during the planning period and it requires high-level approval from the CAB in conjunction with management.
A good example of a Major Change scenario in IT would be the implementation or change of an Enterprise Resouce Planning (ERP) solution. After the submission stage, workforce preparedness is assessed and the organization and stakeholders are properly identified. A project approach is recommended for this type of change, so the milestones of the aforementioned project are determined as well as its deliverables and critical success factors.
Additionally, being able to forecast what the transition process will be after the implementation is a must. If the ERP implementation is labeled as successful, the major change can be closed and post-implementation tasks such as job redefining and competency exercises should be carried out and evaluated.
Minor Change
As their name implies, minor changes include low-risk and low-impact changes. It is important to note that though they are low-impact, that doesn’t mean they are non-trivial (a common misconception). Speaking of common misconceptions, minor changes involve all stages of the Change Management process, since they aren’t frequent. Because of that, they also require approval from the CAB before they can be carried out. It would be correct to assume that these changes aren’t taken lightly despite their name. They are extensively documented and archived, with the additional possibility of becoming standard changes down the road.
An example of a minor change could be updating or upgrading an in-company portal or a workflow management system. Though a good deal of onboarding and communication is required between the stakeholders, service delivery and production continuity are rarely put at risk of jeopardy. A Request for Change (RFC) will be needed of course, and it should include a description, a business justification, and a stipulated implementation timeline for it to be approved.
Standard Change
These differ from the previous two changes in that they are periodic. They do share some ground with minor changes because they also tend to be low risk and impact. The biggest distinction lies in how their approval system works. Standard changes often have set standard operation procedures baked into their deployment. As a consequence, they are pre-approved and pre-defined. Since they are periodic by nature, the change management stages are simplified and they don’t require CAB approval every single time.
A classic case of Standard Change would be patch deployment. Implementing patch deployment requires inventorizing the IT infrastructure’s components, determining the sensitivity and risk rating of said infrastructure, developing a test environment, testing the patch in question, and maintaining it. A description stating the implementation timeline and plan is also crucial as well as a closely monitored development of the testing environment, and back-out plan.
Emergency Change
From all the Change Categories, Emergency Changes are the ones that require swift resolution due to their unexpectedness. Some exceptions to Change management are to be expected as this allows for a much quicker change.
A rather unpleasant but very real issue that might arise is an IT system security breach. If this happens, the RFC could be evaluated either during or post-implementation. Likewise, an extraordinary emergency CAB may have to step in and assess the change as well as hasten the approvals. The most critical part of an Emergency Change is certainly its post-implementation review. This is due to the fast nature of Emergency Changes and their propensity to bring bigger issues in the long run if they aren’t scrutinized correctly. This will not only give CABs a confirmation of just how successful the implementation was post-crisis but also provide them enough information to avoid such problems in the future.
Keep in mind that —following ITIL best practices— post-implementation documentation must be detailed too. Emergency change plans may allow for a communication plan, test plans, back-ups, roll-back restoration measures as well as a review of the test plan (provision for performing test transactions included).
Closing thoughts
Changes in ITIL offer a wide variety of approaches and which one best suits your business is entirely up to you. The main takeaway from learning these categories is that each one of them requires a different set of tools and managerial decisions. Whether you’re looking to scale up, set up a monthly update plan, or be prepared for an unexpected problem, knowing how to deal with each scenario is paramount to running a successful business and we hope it’s been of aid.
Frequently asked questions
What is change management?
ITIL change management is a process designed to understand and minimize risks while making IT changes.
How can I better implement changes in my business?
For this particular question, there’s a fantastic quote by HR SubReddit user and business insider Chad Kosten that reads:
“Employees are going to be naturally resistant to change. Therefore, whenever a company wants to undergo change it's best to have HR involved, since we are usually the "people experts" of the company. Change management can include anything from creating teams to foster the change, when and how to roll out communications for the change, timelines for change, or just being a part of the discussion for change.”
Which are the main Change Categories?
The main Change Categories are Major Changes (for changes that require all hands on deck), Minor Changes (for bite-sized changes that don’t require large-scale, all-encompassing initiatives) Standard Changes (for periodic routine changes that are presumably already part of a company’s roadmap) and Emergency Changes which are pretty self-explanatory as they only pop up when urgent measures must be taken.
Which are the steps towards a successful change?
The five steps to a successful change are as follows:
Acknowledge and understand the need for change. Resisting the temptation to quickly jump to a solution is important as understanding the scope and reach of the hypothetical change allows failure to be a less likely outcome. Some frameworks facilitate stakeholder analysis when trying to understand why a certain change is needed so starting from here is a good idea.
Communicate the need and involve people in developing the change. After the situation has been explored and the reasons for the change have been laid out, communicating these changes to the CAB is what will determine if the change should take place or not. Letting stakeholders know how the change will affect the business allows them to express their opinions and concerns which in turn generates less friction during the actual deployment.
Develop change plans. After communicating and developing a shared understanding of what the change will entail, the planning needs to be as clear as possible. Be precise. What will change, exactly? What’s the objective? How will these affect performance? Develop schedules and plan out the deployment.
Implement change plans. Make sure that everyone knows what exactly will happen and what role they’ll play. Support teams through the change. Additionally, one should maintain the business’s routine as far as it is possible. By following this tip, companies will be able to better assess reactions to the change in question and how to better implement changes in the future.
Evaluate progress and celebrate success. It may seem a bit obvious but acknowledging and thanking people’s involvement in the change should be part of the course for any successfully implemented change. It’s good practice to always accompany this with proper detailed feedback.
