Blog

IT Change Management

Iggy
Apr 6th, 2022
Share

In this post you will learn:

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.

What is IT change management?

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.

What is a change?

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.

What are the change 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.

What isn’t a change?

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.

What is the IT 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.

1. Initiate

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.

2. Review

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.

3. Scope and Plan

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.

4. Approve

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.

5. Implement

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:

  • Build
  • Test
  • Release
  • Deploy

In DevOps, the workflow is usually automated. Careful management and open communication keep stakeholders aware of planned service outages or other effects.

6. Review

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.

Who performs IT change management?

Many roles contribute to this collaborative, multi-departmental process:

  • Engineering leads help identify planned changes. This role contributes to long-term strategies and plans standard changes.
  • Core developers write changes to the code base, from patches to fresh code that introduces new features. This role also does the heavy lifting on normal and standard change requests.
  • Operations teams mitigate issues and make changes related to infrastructure.
  • Security teams take care of security hygiene, including third-party tools and APIs.
  • Technical support and incident management is client facing and triages incidents submitted by external uses. This role specializes in change requests for problems that require development work.
  • Change advisory board acts as a gatekeeper on behalf of an organization’s business interests. This role assesses and takes responsibility for the risk of making changes and controls whether a change is released or sent back for more work.

Why follow an IT change management 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.

Security

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.

Efficiency

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.

Quality

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.

Make rapid change safe with Transposit

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.

  • Reduce risk, with guardrails: Transposit enables teams to build sophisticated workflows across their stack. Operations teams can provide self-service infrastructure and other actions that are secure and consistent.
  • Maintain operational visibility: Transposit provides visibility into all the activities happening throughout the pipeline and infrastructure so teams can quickly understand what’s happening across services and what needs their attention.
  • Stay agile, with governance: Workflows with guardrails and full operational visibility ensure that operations teams can maintain governance while enabling development teams to stay agile and move fast.
Share

Sign Up For Our Newsletter

Subscribe