The Ultimate Change Management Guide!
As a part of continuous improvement, IT systems must be continuously evolved, upgraded, and changed which can lead to potential loss of services, issues, and side effects.
What is Change Management?
Change management is implementing and managing “change” in a Software, Telecom, Cloud, Network, Data Center, or similar IT service environment in any company. Any IT environment is a very dynamic system, very similar to a human body where the circulatory system and the organs work in tandem. Even in a stable looking system, there are degradations happening at micro level which need to be corrected and kept in check. These degradations may be due manual errors or mistakes, wear and tear of hardware, minor power fluctuations, ageing hardware, continuously running circuitry, peaks and dips in traffic levels, incompatibility between two hardware devices or between hardware and software, physical changes like cable twist, cable pinch, etc.
Reasons for change management:
One of the major reasons for change is “Maintenance”, but it may be due to upgradations or degradations or addition of new software or hardware elements. Below is a non-exhaustive list of reason for change management.
- Implementing new software and/or configuration
- Deleting old software and/or configuration
- Migrating data/configuration/port from one to another
- Upgrading or Replacing dying, faulty or end of life hardware
- Improving performance – speed, efficiency
- Correcting errors
- Upgrading systems to new versions or latest releases
- Security updates and patches
- Reduction in costs (often for saving vendor’s costs)
What is the impact of change?
It is extremely crucial to make changes only when there is zero or minimal impact to running systems, customer traffic or production network. Any changes which can negatively impact customer(s) in a production environment can adversely affect customer revenue, vendor reputation and cause customer escalations and frustration. Do consider that even at the customer level, there are many stake holders who need to be considered while implementing a change.
Vendor/Supplier or Service provider’s reputation can be severely impacted in case of loss of customer’s services, data, or revenue if their business is impacted and if their customer’s experience poor service during such times. It is hence mandatory to properly manage change, get approval of downtime. With a structured approach to change management, businesses can reduce the risk of extended downtime, better performance, and security. Vendors and service providers can ensure the implemented change aligns with the goals and objectives of the change.
Planned vs Emergency changes:
We’ve learnt about planned changes above, but there are times when a vendor or the IT team must do changes at a very short notice. The notice may be as short as a few hours or 1-2 days. This is called as an “Emergency/Urgent Change” / “Emergency/Urgent Works”. These urgent and emergency change windows are planned at a very short notice because there may be a risk of bigger outage or damage to equipment or situation like limited time for physical access on site of works. Note that for emergency and urgent CR/CRQ/CCRs, the customers and stake holders are not asked to approve the change but accept it and make alternative arrangements to reduce or alleviate the impact to their services.
Various Stages of Change management:
1) Planning / CAB Meeting
The first stage in any change is planning of goals and objectives, considering the expected effects and any side effects. There is a separate team / sub-team for this very reason called as Change Advisory Board (CAB). The Change Advisory Board (CAB) holds regular meetings to discuss planned Change Control Requests (CCR) or simply Change Requests (CR/CRQ) which is a change ticket in the CRM or ticketing tool.
As stated in the introduction, it is crucial for change to be planned, its service impact consideration and customers be informed and get their approval. For this reason, change should be done under a defined process such as “change management” and the CAB team is part of the vendor/team which does the change, but it represents the customer’s interests and considerations impacting the customer’s service while also assessing the impact of services within and assisting, guiding and approving the change executioner on whether to approve the change or not, how and when the change should be done and ensures if all customers and stakeholders are notified well in advance. Part of planning stage is to also get an impact list ready which enlists what services and customers will be impacted. Everything in the CAB is documented and a “run-book” is created which acts as a recipe book during the change.
2) Notifying customers & stakeholders about the Change Schedule
As discussed, and documented in the CAB meeting, the action plan defined informing/notifying about the upcoming change. Sometimes there is a length of time, (e.g. few days) where prior notification is necessary for customers. The schedule is usually a weekend day or certain time of midnight or both. If the change is related to working on heights or rooftops a daytime is chosen. If for an outdoor change, forecast of bad weather can be factor, there is a bigger window of time asked for. If customer or any party involved in the change chooses their availability, that is negotiated prior to the change schedule.
3) Testing & Backup
Before implementing any change, it is important to take Backups and save current configurations so that it can be used to rollback. Sometimes this testing is done prior and may be the reason of the current change. Any relevant logs are kept aside for future consideration. Backup is either done automatically periodically or manually just before change implementation.
4) Implementation
Once planning, scheduled date, testing and backups are done and when the schedule arrives, it is time to implement the change. Mostly in the change schedule, there are two windows or time slots given – the bigger window is a range of start and end time of change where outage may occur and another smaller duration of time within that window is given during which the outage may be observed. If the outage exceeds the end time of the change window, it may be considered as an outage by the customer, depending on situations. Vendor and customer / stake holders ensure that the implementation process is smooth and that there is minimal disruption to the service. Sometimes a custodian must be present during the change to monitor their side of things and monitor their before and after. The Change schedule is secret between the customer and vendor due to security reasons, especially if it is a security related change.
5) Monitoring
After the change has been implemented, the vendor monitors the outcome and compares the “after” to the “before” and if the change has produced desired results. If not, this goes back to the implementation stage (within the change window). Customer may monitor it during or after the change window, although they are advised to do it after the change window.
6) Rollback, if any
Sometimes it may happen that change may go wrong or the change while being successful, also produces side effects. Things may go wrong in unexpected ways. During such times, it is necessary to rollback the changes to previously known stable state. For this purpose, the backups and logs taken earlier are useful.
7) Completion and Success/Failure notifications
Once the change executioner / team is satisfied with the outcome of the change, either the change team or any customer facing team notifies the customers of the success of the change and that CR/CRQ/CCR ticket can be closed. If the change didn’t succeed, the customer is informed likewise, and a follow-up CAB meeting decides another date.
Change Documentation
Finally, documenting all network changes, including the planning, testing, implementation, and monitoring phases is as important as the change itself. This documentation helps businesses track and manage their network changes effectively, ensuring that they can make informed decisions about future network changes. This documentation is mostly automated through CRM or other tools.
To conclude…
To sum up, Change management is the process of planning, implementing, and tracking changes to IT systems to ensure that they are implemented smoothly and do not impact service availability or security. Managed service providers like Quadrang Systems comply to ITSM change management principles and processes which are industry standard enabling smooth transition and migration of customers’ services. We document all network changes, including the planning, testing, implementation, and monitoring phases. This documentation helps businesses track and manage their network changes effectively, ensuring that they can make informed decisions about future network changes. This documentation is mostly automated through CRM or other tools.
Contact us for more information.
