How To Manage Change In An IT Environment Using ITIL Best Practices
Last week, I discussed ITIL Foundation, and how, for IT professionals, it is the greatest thing since sliced bread. This week I am going to discuss one of the important processes of ITIL which is change management. As the name suggests, it is about using the correct practices for implementing changes within your IT environment.
What Constitutes As Change In An IT Environment?
Change can be anything from upgrading/downgrading/replacing any IT asset including hardware, software, firmware etc. to ensure smooth operation, optimized performance, better utilization, enhanced features and stability in your IT infrastructure/environment.
How To Manage Change Using ITIL Best Practices
We have all heard a common phrase at one point or another in our lives, and that’s besides being the only constant, change is almost always painful. However, it is not true at-least in IT environments (thanks to ITIL best practices).
ITIL recommends best practices and one of the processes it defines comprehensively is dealing with changes and making transitions smooth. By following ITIL best practices, we can reduce ambiguity, prepare for surprise elements and counter unexpected results which lead to failures. No matter how good a change appears to be on the surface, you can’t just implement it right away and expect the desired output. You’ve got to go through a systematic procedure which includes documentation to avoid business discontinuity or loss of production/revenue.
Where Does Change Management Fit in ITIL?
As I mentioned, change management is one of the 26 processes defined in ITIL Foundation Certification. It belongs to the service transition stage of IT service lifecycle. It recommends steps needed for implementing or incorporating a change.
Examples of Change Recommended Within IT Environments
Let’s say you represent an IT setup which uses databases and you have been advised by your database vendor to upgrade your hardware from 32 bit CPUs to 64 bit CPUs so that a new version of the database can be supported. Your software vendor highly recommends this new version of the database application to be used due to known security threats/concerns. This is an example where you have to incorporate change in your IT infrastructure/resources to avoid vulnerabilities.
Another example of change could be when your in-house software development team advises you to upgrade your server operating system from Windows Server 2012 to Windows Server 2016 due to new features and options they have recently added in your production software. They think that the existing operating system won’t be able to support new software.
Can You Implement These Recommendations Right Away?
1. Request for Change Proposal (RFC)
In either of the cases, you can’t just make a change right away but rather follow a procedure which suggest that you come up with a proposal known as RFC (Request for Change Proposal). In this document, you highlight all the necessary information about your desired change(s) and their justifications. You need to make a case why you think this change is essential and how it is going to benefit overall production and/or efficiency of your business.
2. Change Advisory Board (CAB)
Once done with this document, it has to be presented in front of CAB (Change Advisory Board) which is a team of experts representing various departments of your organization, and in some cases, you may also invite your customer and third-party supplier (if exists) to have their opinion too regarding proposed changes. After having detailed discussions, tabletop exercises and evaluation of pros and cons, a final verdict is made. If change is approved by the CAB, it is not done yet and there is another phase of testing and contingency planning.
3. Testing In a Virtual Environment
In the last phase, the supposed changes need to be tested in a virtualized environment (non-production setup) to observe the impact of change(s). Some changes are irreversible so we also should understand that a plan B or contingency plan is required if in case change doesn’t work the way it was expected.
Once we are done with all the above practices/procedures, chances are that change would likely result in a way we expected and probability of success is high. So ITIL practice/process of change management should be adopted for all proposed changes within our IT environments to avoid any discontinuity in business and un-necessary outages/service interruptions.
In my next blog post, I will be discussing patch management which is basically a sub-process of change management. We will observe its practices and implementation procedures to see how it can benefit us. Please do visit our community portal itexperts.quickstart.com for all the resources/blogs/discussions which are a great source of learning.