IT change management is a standardized process for planning, communicating, and implementing technical changes to information systems. IT Support professionals are often responsible for installations, updates, upgrades, migrations, etc. to an organization’s software, hardware, network security policy, data storage policy, cloud platforms, and more. IT Support staff are expected to make these changes while also minimizing disruptions to the organization’s IT services. By following IT change management best practices, IT Support professionals can create robust plans for change rollouts that protect business continuity. The change management plan is often reviewed by change board approvals, management teams, and/or project stakeholders for risk assessment, feedback, and plan approvals or rejections.
IT change management plans
Each organization will have their own change management policies, processes, and procedures. However, there are several common items that should be included in change management plans as a best practice. When proposing a change, IT professionals may create documentation or use change request forms to detail the following elements:
- Person/team responsible for the change: Names at least one person as the responsible party for overseeing the change management plan.
- Change priority: States the urgency of the change. For example, critical security patches would have a high priority and need to be scheduled ASAP. Whereas, a software update that merely adds new features might be a very low priority and can be scheduled for a convenient future date.
- Change description: Gives an overview of the planned changes. The change description should also provide a list of the planned changes. For example, if the change involves updating firmware on several router models, the description should include which routers and models will be updated. Additionally, the plan should list the old firmware versions currently on the routers along with the new firmware versions to be applied during the update.
- Purpose of the change: Explains why the change is necessary. For IT Support professionals, the most common reasons for changes are operating system, software, driver, and firmware patches and updates, as well as hardware and peripheral upgrades. Installations, implementations, and redesigns of software and hardware systems are also common IT changes. IT Support professionals should regularly evaluate the need for improvements and changes to network security policies and procedures. Laws, regulations, and company policies may also require changes to how organizations store, transmit, and protect data.
- Scope of the change: Describes the extent of the changes. The documentation should include a list of all IT systems (hardware, software, etc.), locations, departments, individuals, vendors, partners, customers, and others the changes affect, whether directly or indirectly. Any changes to policies, processes, or procedures should also be recorded.
- Date, time, and duration of the change: Indicates when the change is scheduled to take place and the duration of the change rollout. If the change is expected to create service outages, the person or team responsible for managing the change should inform all affected staff about the outage before the systems are taken offline. IT changes are often implemented outside of normal business hours, when systems can be taken offline with minimal disruption. For organizations with traditional Monday through Friday, 8 a.m. to 5 p.m. business hours, changes are usually planned to begin in the early evening on a Friday, after end users have logged out for the weekend. The change implementation process should include plenty of contingency time before the next business day in order to test, troubleshoot, repair, and roll-back any changes that are not successful. When an unsuccessful change occurs, IT Support professionals may need to work through the night and into the next morning. Organizations and IT departments may opt to hire a vendor to perform overnight system changes to adhere to company overtime policies and labor laws.
- Change rollback or backout plan: In case of primary plan failures, details a rollback plan to return the affected systems back to their original state before the changes were attempted. Additionally, a secondary or alternative plan may be included. This could be a plan to activate a failover system to replace any problemed systems until they are repaired. IT Support professionals should detail the steps involved in the rollback and/or alternative plans, including the original configuration settings and software, patch, driver, and/or firmware versions. Files needed to rollback updates and patches should be downloaded and stored in an accessible location to simplify rollbacks. Cloud-based virtual systems can be restored in seconds by simply using clones of saved previous VM states.
- Technical evaluation: Records the results of any testing performed on the proposed changes in a lab or sandboxed environment. The testing environment should be as similar to the target environment as possible. For example, the same operating system versions, hardware parts, drivers, firmware, etc. of the target system should be reflected in the lab/sandbox testing environment. Setting up a testing sandbox for cloud platforms should be as simple as cloning the virtual system(s) targeted for updates. The plans should also include metrics for evaluating if a change is successful or not.
- Systems affected by the change: Lists all IT resources (including hardware, software, networked, and cloud systems) that will experience direct or indirect changes as a result of the change rollout.
- Anticipated impact of changes: Describes how the planned changes are expected to impact the affected systems. For example, if the change involves adding new servers to a resource pool, the plan might describe that this increase in load capacity will result in system performance improvements and faster server response times.
- Resources needed to implement the change: Lists the human resources, budget, time, management oversight, subject matter expert (SME) consultations, training, equipment, hardware, software, parts, systems, tools, insurance policies, and any other resource needed to complete the planned changes.
- Training for users impacted by the change: Outlines any training needs to help users adapt to the changes. This might include classes on how to use new software applications, hands-on practice with new hardware, a company-wide announcement for security procedure changes, and more.
- Risk level for change: Describes how much risk is involved in making the proposed changes. Some changes are high risk and might cause catastrophic failures if the plan goes wrong. For example, an upgrade involving a single point of failure on a critical system could create a system-wide outage. In this case, it would be wise to implement a redundant failover system for that critical system before attempting any other changes.
- Change instructions: Details each step of the planned changes. This should be formatted as an instruction manual for the IT Support professionals to follow to ensure there is no guesswork involved in implementing the changes.
Change board approvals
Some large organizations may have a Change Advisory Board (CAB). The CAB is a board of directors appointed to oversee all implemented IT changes in the organization. The CAB can be the official governing body to approve or deny change management plans. They may advise on needed adjustments to the plan to meet business goals or to comply with regulatory compliance criteria. The CAB may also assist with mitigating risk brought about by proposed changes.
User acceptance
Including a user acceptance process for information system changes is a best practice in IT change management. IT change management plans can include a beta testing period similar to software development user acceptance testing. This plan might include several days of testing by a select group of users to ensure that the changes have been successful and that there are no hidden surprises caused by the changes. The change management team for the plan should develop user acceptance criteria forms for the beta testers to complete. The criteria normally includes common activities that all end users should be able to perform successfully in the new or changed environment. A period of time should be reserved for fixing any problems the beta testers find. When beta testing is successful and the changes have been accepted/approved by the users, the changes should become available to all appropriate end users.
Cloud computing: The concept and technological approach of accessing data, using applications, storing files, etc. from anywhere in the world as long as you have an internet connection
Data center: A facility that stores hundreds, if not thousands of servers
Deployment: Hardware is set up so that the employee can do their job
IT Infrastructure: The software, the hardware, network, and services required for an organization to operate in an enterprise IT environment
KVM Switch: Keyboard, video, & mouse switch that looks like a hub that you can connect multiple computers to and control using one keyboard, mouse, and monitor
Maintenance: Where software is updated and hardware issues are fixed if, and when, they occur
Procurement: Hardware is purchased or reused for an employee
Production: The parts of the infrastructure where certain services are executed and serve to its users production
Reproduction case: Recreating an error to test a solution to make sure the problem is gone after a fix has been applied
Retirement: Hardware becomes unusable or no longer needed, and it needs to be properly removed from the fleet
Rollback: Reverting to the previous state before you made changes
Secondary or stand-by machine: A machine that is the same as a production machine, but won’t receive any traffic from actual users until enabled
Server: Software or a machine that provides services to other software or machines
System Administration: The field in IT that is responsible for maintaining reliable computer systems, in a Multi-user environment
Test environment: A virtual machine running the same configuration as a production environment, but isn’t actually serving any users of the service
