Change management is a standard IT service management insurance program. In the context of IT, the process ensures that established methods and procedures are used efficiently to handle all changes to IT infrastructure to minimize the number or impact of possible incidents during the service.
Now let′s translate this to English.
What this basically means is that IT change management (ITCM) is used to regulate the changes made to a product or system and ensure that there are no malfunctions, errors or related issues for users. It requires proper coordination, communication and oversight to be efficient. IT change management also ensures (or tries its best to ensure) that no negative side effects of any change will impact your company′s IT system.
It′s important not to confuse this with organizational change management (OCM). OCM manages business environment related changes that include IT changes, structural changes or cultural changes in the company.
To put it simply, ITCM refers to products or services and OCM refers to people. /Tweet this
The thing is, OCM changes are always pretty much optional: you may or may not choose to change your organizational structure (maybe like have your assistants report to an assistant manager who then will report to you) or cultural changes (Friday is beer day!).
In case of ITCM though, changes are often necessary and don′t ask for your opinion (sorry guys). Say for example the barcode standards change in your country. If you want to continue selling your products (and I imagine you do) you will have to adapt. Or if any governmental level changes occur (like tax related changes) you may want to adapt not to go bankrupt next week.
This is why it′s crucial to be prepared for such situations and have a plan ready in case you need to undertake any changes related to your products or services. Here is a list of simplified, standard procedures you need to know about.
1. Request for change
This is the first phase where the change initiative originates from. It may be:
-
Business related changes ”“ when the company wants to make changes to their service/product and needs the corresponding support of IT department
-
Risk management changes ”“ when a risk is identified by risk management department and change is needed to mitigate any possible future damage
-
Government related changes ”“ as mentioned before, something that has nothing to do with your company, but you still need to be aware and adapt to those
2. Approval from the company
Even when a change needs to be undertaken, it′s not your responsibility as the IT manager to decide whether the change should take place or not. Any business related change (including IT, since it will have an impact on the overall business in one way or another) is basically weighting the ups and downs of the proposed approach.
Since every change is related to a certain amount of budget, you will need to get approval from people who are in charge of distributing that budget for any sort of initiatives within the company.
3. Change development
The development of the change is under your jurisdiction. For any emergency issues, your actions are almost always predetermined: there isn′t much to think about, you just need to fix stuff ASAP.
When developing a new system, your department needs to work with the business users. So basically the following happens:
-
You guys design the system, they approve it
-
You guys develop the system according to the design
-
Both parties test the system
-
Final product is approved by IT and users.
4. Change advisory board approval
For the purpose of implementing the change, a CAB is put together in the company. In standard situations the board consists of different people with different areas of expertise and backgrounds. The board will be required to review the change from a government perspective and also make sure that all possible risks are taken into account and nothing that can go wrong is missed.
5. Change implementation
Depending on the outcome of CAB approval (negative, positive) your department will either have to review and fix any issues due to which the plan was rejected, or proceed with the implementation.
6. Reporting the results
Typically, there can be a few outcomes of the change:
-
Change was implemented successfully
-
A number of issues arose during the implementation and were fixed on the go
-
Issues arose during the change that fall in the range of “acceptable”
-
Issues arose during the process that rolled the change back
-
Alarming issues arose during the process and the change couldn′t be rolled back
Regardless of the outcome, it should be presented to the CAB and they will be responsible for any further communication with all involved parties, documentation, etc.
7. Monitoring
Even after successful implementation of change, it should still be monitored for any possible issues that may arise in the future. Oftentimes, issues arise not right after the change is implemented, but rather some time later.
For example adding several fields to a database may seem useful for users and not have any negative impact, but in the long run, the addition can pressure the whole system so that it starts to work slower, which in turn will affect the users.
As you probably understood, ITCM is a complex, pain in the ass, but necessary process that every IT manager should be familiar with and ready to execute when the time is nigh. Don′t get discouraged though: think of it as a process like any other. It just needs to be done, and done well. Cheers guys -)
Follow us
