How Change Management Works in IT Industry

Change Management is an approach to transitioning organizations, teams and individuals from their current state to a new desired state for the future. The purpose of Change Management is to establish standardized procedures for the handling of IT-related change requests and facilitates the assessment, scheduling, coordination, documentation and evaluation of all changes.

A Change can be initiated both from within the organization and from external forces. Externally, competition may drive an organization to change a product. Internally, a problem may be identified and change management is seen as the process by which a solution can be implemented with the organization.

Change Management Process

Creating Request for Change

The Request for Change (RFC) record is created for a desired change to be implemented in service management tool with a unique ID. All the associated risks and implementation tasks should be listed through the RFC form.

Reviewing and Assessing a Request for Change

  • Check for completeness of the change request.
  • Evaluate the request based on its viability and priority.
  • Approve submission of change request.

Change Approval must be based on the Following Questions

  • Why is the reason for the change?
  • What is the benefit of the proposed change?
  • Who raised the change?
  • What are the associated risks?
  • What are the required resources to implement the changes?
  • Is the change urgent or can be postponed?
  • What will be the impact on the other IT configuration and services?

The approvals of changes are done by the Change Advisory Board (CAB). RFC’s are reviewed, action items generated and processes discussed. If an RFC is approved by the CAB, the proposed change can go ahead. If not enough information or details are present in an RFC, CAB can either deny the RFC or ask for action items to be completed before the change can be approved.

Planning the Change

Once the change request is made, the entire course of actions for the change should be planned. The required resources and the timeline for implementation will have to be decided.

Testing the Change

The change will be tested for their functionality and accuracy, as well as their compatibility and operability. The testing will be done in an environment replicating the production environment. It includes procedures to install the proposed change, back out steps in the event it cannot be successfully implemented, verification steps that the environment has been restored to the initial configuration that existed prior to the change attempt and that there are no negative side effects resulting from the attempted change. A remediation plan must be framed, including procedures to back out at various stages of the change.

Creating a Change Proposal

Drafting the description and type of change; the priority associated with it, costs associated with the change, benefits and consequences of applying and not applying the change. The proposal should be sent to the person authorizing the change.

Implementing the Change

Once a change is planned, communication about the rollout, timeline and implementation has to be made. Remind everyone of his role as your company begins to implement the change. Those in charge of monitoring the change must do so closely, communicating with other involved parties. Changes should be made in the order that affect the process and the employees who manage the process.

Post Implementation Review

The post-implementation review is required to determine the success/failure of the change. It is performed according to the testing procedures defined during the change building and the results are recorded. If the PIR does not attest to a successful change, a rollback must be triggered.

The following evaluation questionnaire should be considered for the PIR:

  • Did the change meet the desired targets?
  • Was the change implemented in time?
  • Did any incidents occur while the change passed through the process?
  • Was the change performed without exceeding the assigned budget of money?
  • Has the change been documented?
  • Did everyone involved in the change follow the process?
  • Was any information missing, which was needed to make a decision at any stage of the process?

A review should also include any incidents arising as a result of the change (if they are known at this stage). Lessons learned should be factored into future changes.

Change Closure

Once the change process is complete, the entire process must be documented for reference in future. The change is closed after every step of the change process and every status change of the RFC must be documented in the configuration database. The change success, failure, related plans, etc. are communicated to all stakeholders.

Types of Change Categories


Types of Change Priorities

The following status codes can be used to reflect the status of a change request

  • Open − The change has been created and accepted but has not been assigned to an owner.
  • In-Progress − The change has been acknowledged and assigned to an owner.
  • Approved − Both the business and technical leadership teams have assessed and the change has been approved.
  • Rejected − The change has been rejected and will be routed back to the requester with an explanation and a recommended course of action.
  • Closed − The change request has been closed.
  • Canceled − The change request has been canceled.

Change management is one of the most important service management processes. The organization will have knowledge of the process of a change, the obstacles that need to be crossed to reach the end goal. The usage of change management will ensure that the majority of the workforce affected by the change embraces and adopts and is proficient at the required change. It also gives a positive effect on employees impacted by the change, finishing on time and finishing within the planned budget.

Samual Sam
Samual Sam

Learning faster. Every day.