The most flexible no-code ITSM solution
IT Change Management is the process of planning, approving, implementing, and reviewing changes in IT systems or services with minimal disruption. It's part of IT Service Management (ITSM) practices and is especially important in environments that require high availability and strict compliance.
The goal is to balance speed and control, allowing teams to implement updates or fixes without jeopardizing service reliability.
A Change Management model is a framework that outlines how to plan and carry out changes in a structured way. While ITIL focuses specifically on IT service changes, broader models help guide the human, cultural, and organizational side of change.
They're relevant because they offer proven methods that reduce resistance, increase alignment, and create a roadmap for complex shifts — whether you're rolling out a new ITSM tool or reshaping your company structure.
Change is one of the most studied topics in both business and psychology because it affects every layer of an organization, from tools and processes to teams and leadership. It’s never just about implementation; it’s also about acceptance, reinforcement, and continuity.
That’s why models from different disciplines are not only valid but often necessary in IT contexts. In fact, ITIL has gradually moved away from the term “Change Management” and now refers to “Change Enablement,” acknowledging that successful change involves more than approval workflows — it requires collaboration, planning, and adaptability.
Research by Gartner supports this broader view of Change Management. According to their findings, traditional top-down approaches are less effective in today’s work environments.
Organizations that adopt an open-source change model — where leaders actively involve employees in shaping strategic decisions — can increase their chances of successful change from 34% to 58%. In these environments, employees don’t just receive instructions; they help design how the change will be implemented.
The ITIL framework treats Change Management (now "Change Enablement" in ITIL 4) as a formal process designed to minimize the risk and impact of changes in IT environments. It divides changes into categories — standard, normal, and emergency — based on urgency and complexity, and outlines different levels of approval and assessment for each.
At the core of the model is a structured workflow: logging the change, assessing its risk and potential impact, getting it reviewed (often by a Change Advisory Board or CAB), implementing it in a controlled way, and then closing it with a review. Roles like the Change Manager support the process, which is often integrated with ITSM tools to maintain audit trails and ensure coordination across departments.
While it's procedural, ITIL Change Management is highly customizable. For example, standard changes (like routine software updates) can be pre-approved, while higher-risk changes require detailed risk analysis. The idea is not to block change but to manage it with enough control to protect service quality.
“We need to start looking at change as a flow, we need to look at it as 'how do we engineer quality into the process so that the things that come out of the end are at the level of quality that we desire?’ That's the focus of Change Management. Change Management should be more of an oversight and governance role.”
Director of IT Support at Taylor Morrison
Large organizations or enterprises with mature IT operations, regulated industries, and teams already using ITSM platforms. It's ideal where there's a need for strict control, visibility, and coordination between IT and business functions.
Kurt Lewin’s model breaks change into three distinct stages: unfreeze, change, and refreeze. It's one of the earliest models of organizational change and focuses on the emotional and psychological aspects of disruption.
Lewin’s model is particularly effective because it simplifies the process without oversimplifying the emotional resistance that often comes with change.
Organizations undergoing cultural or structural changes — such as adapting to remote work, shifting management styles, or merging departments. It suits environments where buy-in and mindset change matter more than technical procedures.
The ADKAR model focuses on individual transitions during change. Rather than describing how to design a change program, it outlines the stages a person goes through when adapting to something new. Each letter in ADKAR represents a goal that must be achieved for change to stick:
ADKAR is particularly useful for identifying where change efforts break down. If people understand the change but don’t want it, the issue is with Desire. If they want it but can’t do it yet, the problem lies with Ability. This structure makes it easier to tailor communication, training, and support to the specific barriers people are facing.
Any organization where people’s behavior is the primary success factor — for example, rolling out a new tool that requires training and attitude change. It’s often used by HR, communications, or Project Management teams alongside technical change plans.
John Kotter’s model presents change as a leadership-driven process that unfolds in eight stages:
The steps are meant to be followed in order, though they can overlap. The strength of Kotter’s model is its emphasis on leadership and momentum. It’s designed to avoid change fatigue by building engagement early and celebrating visible progress along the way.
The later steps focus on making the change stick, not just finishing a rollout — a common failure point in large initiatives. It’s especially helpful when change involves cross-functional teams or depends on influencing culture, not just processes.
Organizations managing strategic change, such as digital transformation or a shift in business models. It works well when leadership is aligned and ready to take an active role in guiding the change process.
Unlike models that focus on steps or phases, the McKinsey 7-S model provides a snapshot of organizational alignment. It identifies seven elements that must be considered when introducing change:
The model emphasizes that these elements are interconnected. If one changes — say, a new strategy — the others must also adapt. Otherwise, the organization becomes misaligned.
It’s most useful when changes are large and multi-dimensional. For example, moving from a product-based model to a service-based one affects everything from how people are hired to how performance is measured.
Organizations that are going through complex, enterprise-wide changes, such as a merger, rapid expansion, or operational overhaul. It's useful when you're trying to change more than one area at once and want to keep alignment intact.
Developed by William Bridges, this model focuses on the psychological transition people go through during change rather than the external change itself. Bridges argues that change happens quickly — the switch to a new system or structure — but the emotional transition people experience takes much longer and needs to be managed consciously.
The model has three phases:
What sets this model apart is its focus on helping individuals let go of the past rather than just adopt the new. It emphasizes communication, empathy, and support through each emotional stage.
Organizations going through changes that disrupt how people view their role or identity — like leadership changes, rebranding, or downsizing. It’s especially valuable for HR teams and people leaders guiding employees through difficult transitions.
This model breaks down organizations into interconnected layers, showing how deep changes in strategy or leadership influence systems, teams, and individual behavior. It emphasizes the difference between transformational factors (like leadership and culture) and transactional factors (like structure and systems).
The framework includes twelve components — from external influences and mission to motivation and performance. Change typically starts with external pressures or strategic shifts, which then cascade through leadership behavior and organizational culture, and finally impact day-to-day operations.
It’s primarily used to assess where change needs to happen and predict how shifts in one area will ripple through the rest of the organization.
Large organizations that are facing structural or strategic transformation. It is particularly helpful for mapping complex interdependencies before rolling out change at scale.
This model applies Agile principles to Change Management efforts. Rather than treating change as a one-time rollout, it supports incremental adjustments, quick feedback loops, and flexibility.
It typically includes:
Instead of relying on fixed timelines or top-down control, this approach lets teams iterate and adapt, often using backlogs, retrospectives, and other Agile tools to steer progress.
Digital and software-focused environments or any organization operating in fast-moving conditions. Particularly effective for transformations where user feedback and continuous delivery are key.
Originally created by Elisabeth Kübler-Ross to describe the stages of grief, the model has been adapted widely in Change Management to understand emotional reactions to change. The stages are:
Although the Kübler-Ross curve wasn’t designed for business, it reflects how people react to disruptive change. The adapted version is often used to guide support strategies — helping leaders anticipate resistance and respond with empathy.
Some organizations add additional stages like “exploration” or “commitment” to reflect eventual engagement with the new way of working.
Companies implementing changes that are emotionally difficult or disruptive, such as layoffs, restructuring, or major culture shifts. It's a tool often used by change agents and coaches to understand team reactions and plan support accordingly.
Also known as the Deming Cycle or Shewhart Cycle, PDCA comes from quality management and continuous improvement principles. It was popularized by W. Edwards Deming and focuses on a repeating four-step process:
PDCA promotes incremental improvements and learning through iteration. Rather than relying on one big change, it supports a cycle of small tests, reflection, and adjustment. It also encourages measurement and documentation.
Process-focused teams like IT operations, manufacturing, or quality assurance, especially when rolling out recurring or small-scale improvements. It’s also a good fit for organizations with a Kaizen or Lean culture that values experimentation and data-driven decision-making.
Read other articles like this one: