The nature of today's rapidly developing technology landscape means change is inevitable. IT change management is a process that helps IT teams implement changes on systems and IT infrastructure. The process is carefully designed to mitigate risk and ensure current service is not interrupted while changes are being made.
IT change management is an important process in IT service management. It’s all about standardization, which empowers team members to do consistent work that aligns with plans for minimizing risk while implementing changes.
Here’s a fun fact: this methodology came about fairly recently, as a result of the collaboration between cybersecurity professionals and the military. The engineering operational models for managing change grew under the influence of military processes, as the collision of these two worlds amplified the importance of de-risking change and the protocol around it. For IT teams, managing change came to mean systematically logging, classifying, and planning to mitigate risk during system changes. This process was formalized under the Information Technology Infrastructure Library (ITIL) change management process.
Over time, the concept of IT change management evolved to accommodate newer, more granular approaches to change requests. Some teams have replaced older development frameworks, like waterfall development, with new ones like Agile development — but they haven’t replaced IT change management. With a few tweaks over the years, it’s stayed relevant.
So, change management is how teams manage change. Understanding the process starts with knowing exactly what “change” means in IT.
In IT, a change, or change management event, usually involves a whole collection of engineering tasks. And seen through the lens of IT change management, no change is singular.
Organizations often use support tickets to formally request work from engineers. A customer could report an incident, a project manager could expand the scope of a release, or an engineer could discover a problem with the code. Resolving a ticket is making a change, but the scope of the work will vary.
Not all changes come about through tickets, though. Change management teams can also contribute to large-scale business operational projects, like creating endpoints in a server farm or to support hires at a new branch.
To help sort and prioritize such a wide variety of work, IT change management teams classify change requests into types.
IT professionals use a common language to classify changes within precise categories. This system makes changes easier to assess and predict, even under stress. There are 4 common types of change: standard, normal, major, and emergency. All but emergency changes are scheduled.
Standard changes are minor, low-risk change events associated with general system improvements, such as operating system updates. They’re kind of like brushing and flossing — simple but important acts that maintain hygiene. Like healthy habits, standard changes usually happen frequently and on schedule.
Normal changes happen at the right opportunity or as part of a project. They’re usually important planned improvements that serve a goal. For example, changes that revise firewall policy, switch vendors, or migrate platforms are normal. Most beneficial changes are considered normal. It’s the broadest category of change.
Major changes aren’t usually urgent or unexpected, but they carry more risk than normal changes. Technologically complex and expensive changes are major. They need to be planned.
Emergency changes are unplanned changes that address software emergencies. Security breaches, severe defects, and critical failures are all examples of software emergencies that require this kind of change.
In DevOps, continuous improvement is baked into change management, and so is automation. The change management process is evolutionary, over time making normal and major changes into standard ones — by automating them.
Changes overlap with 2 other IT categories — incidents and problems — but they’re not the same. Here’s the difference.
Incidents are unplanned events that disrupt service on live projects. Through the incident management process, IT teams restore service as quickly as possible.
Problems can be negative — the root causes or contributing factors of incidents. They can also be neutral — complex engineering projects that need to be worked through, such as figuring out how to integrate software. The problem management process helps IT teams identify problems and the steps to fix them.
Where do changes fit in here? In a cycle with these other events. Changes are associated with newness (new requirements, new features, or new deployments of infrastructure). With anything new, something unforeseen could come up — that’s an incident. After incident management mitigates the immediate issue, problem management seeks to identify a cause or pattern that may lead to a change: the start of the cycle again. What comes next depends how that change is identified, categorized, planned for, and implemented within a standardized change management process.
As the field of IT evolves, change management has become more flexible, but core concepts have stayed the same. The process starts with identifying a change and moves through phases mapped out in a change management policy.
Identifying a change initiates change management. The change needs to be logged, described, evaluated, and classified. Many organizations make change requests formal, using service tickets. In DevOps, self-service ticketing makes requesting a change accessible for the right people, and multiple teams collaborate from the beginning. This stage involves gathering information that will be used to scope and plan.
Managers, stakeholders, or an automated system could review the change in a DevOps context. With the right conditions and systems in place, simple changes that meet the right criteria, and don’t need planning or approval, can get automated through the next steps. Otherwise, the review kicks off planning.
Finding agreement on the scope of a change request is a critical part of successful IT change management. During scoping, teams figure out all the tasks required to make the change, defining it as a unit and assigning it a priority. Scoping sets clear, shared expectations to meet.
Planning puts identified tasks in order, considers resources, and produces a schedule. It involves setting out steps and additional remediation steps in case the first plan fails. During this phase, teams identify potential risks and look for ways to avoid them. They figure out how to make the change without disrupting service.
By the end of planning, the team should know the goal of the change, how long it will take, what resources it needs, and what to do if it goes wrong.
Most organizations have a formal approval stage. System changes can be risky and need oversight — sometimes by a change advisory (CAB) board and at a bureaucratic pace. Approval includes considering how the change, and the proposed steps for making it, could affect stakeholders. It includes assessing whether the change is needed and the risks of taking action. Teams could go back to the drawing board at the approval stage. In DevOps, CABs may take the form of advisors and coordinators that participate earlier in the process as well, rather than formal bodies that come in at the approval stage and slow things down.
Streams of work are coordinated, tasks are delegated, and changes get made during the implementation phase. This is a collaborative period that moves through sub-phases:
In DevOps, the workflow is usually automated. Careful management and open communication keep stakeholders aware of planned service outages or other effects.
After teams complete the change, they review. Did it meet its goal successfully? This is the time to finalize small details — or put a remediation plan into action. When everything wraps up, the change request can be marked closed. Since communication is key in DevOps, reporting on details of how the change went is part of closing it. Learning from successes and challenges feeds the team’s continuous improvement of their approach, and it’s part of approaching change proactively.
Many roles contribute to this collaborative, multi-departmental process:
Change management is an engineering concept that stands the test of time. It’s stayed relevant by evolving to fit Agile approaches. The iterations of the process that are used by today’s teams may look quite different from the original, but they honor its foundation. Modern IT change management brings more benefits to IT teams than ever.
A critical benefit of IT change management is security and privacy protection. A successful strategy has policies for both hygiene and emergencies. Hackers are always learning new tricks for compromising environments, but regularly scheduled maintenance buttons up emerging vulnerabilities quickly. If someone infiltrates anyway, IT change management makes sure there’s a plan of action already in place.
Standardized processes are the bread and butter of change management. When everyone knows their role, what they’re responsible for, and what steps to take in different situations, they don’t have to waste time figuring all that out when something comes up. With planning, the right people will be available at the right time and prepared to act.
There’s too much room for error in IT to go without change management. If a change request gets misdirected, it might not get done — or it could go forward without authorization. There might not be a remediation plan for a change, leaving a team scrambling when something goes wrong with plan A. Change management helps teams act in a collaborative, considered way, and track progress, producing consistent results that align with goals.
Transposit’s fully integrated, data-driven approach enables teams to make rapid change safe across operations. Harnessing the power of both human and machine data across SaaS apps and APIs, Transposit empowers teams to incrementally automate processes and maintain end-to-end visibility across the software and infrastructure lifecycle.