You Heard It in a Meeting. What Did They Actually Mean?
If you work anywhere near software, IT, or business operations, you have almost certainly heard the phrase “change management” in a meeting. You probably nodded along. You might not have been entirely sure which kind of change management the speaker meant — and there is a reasonably good chance the other people in the room were not sure either.
That is not because anyone in the meeting was confused about their work. It is because “change management” is one of those unusually unlucky phrases that evolved independently in three different professional communities, each of which now uses it to mean something completely different from the other two. When those communities end up in the same meeting, the word becomes a trap.
A director of engineering, a head of IT operations, and a VP of HR can all agree that “we need better change management” and leave the meeting intending to do three completely unrelated things. Each of them will be right — about their own definition. None of them will have actually agreed on anything.
This article is a guide for anyone who has heard the phrase and wants to be able to tell, next time, which change management is actually being talked about.
The Three Change Managements
Here they are, in the order most software and IT people would naturally rank them:
- Source and configuration change management — git, pull requests, versioned configuration, release engineering. The software engineer’s default.
- ITIL change control — Request For Change (RFC) forms, Change Advisory Boards (CABs), production change windows, rollback procedures. The IT operations default.
- Organizational Change Management (OCM) — preparing people for a new system or process. Communication plans, training programs, adoption tracking, sponsor engagement. The business transformation default, and the one most likely to be meant when someone says “change management killed our project.”
The same phrase. Three different disciplines. Different tools, different frameworks, different people, different failure modes. Let us take them one at a time.
Type 1: Source and Configuration Change Management
This is the one software engineers think of first. In most software companies, “change management” means:
- Code lives in git (or another version control system)
- Changes are made on branches and submitted as pull requests or merge requests
- Another engineer reviews the change before it is merged
- The change is versioned — you can always see what changed, when, and why
- If something breaks, you can roll back to a known-good version
- Configuration for systems, not just application code, is tracked the same way — this is sometimes called “infrastructure as code” or “GitOps”
The goal is to prevent undocumented drift. The failure mode this protects against is: someone makes a change, nobody else knows about it, six months later the system breaks, and nobody can figure out what was different.
If you are in a meeting with software engineers and someone says “our change management is a mess,” this is almost certainly what they are talking about. The fix looks like: adopt git properly, require reviews, write configuration changes as code rather than clicking around in a web UI.
This kind of change management is extremely well tooled. Git, GitHub, GitLab, Bitbucket, review tools, CI/CD pipelines, feature-flag systems, and infrastructure-as-code tools like Terraform, Ansible, and Pulumi all live in this space.
Type 2: ITIL Change Control
This is the one IT operations people think of first. In a data center, a cloud environment, or any production system, changes carry risk — a seemingly innocent patch or configuration tweak can take down a business-critical service. ITIL (the Information Technology Infrastructure Library) is a set of practices for managing IT services, and its “change management” process — more carefully called change control to avoid confusion — is about controlling that risk.
In an ITIL shop, “change management” means:
- Someone proposes a change by filling out a Request for Change (RFC)
- A Change Advisory Board (CAB) reviews the RFC — usually a meeting with IT leads and relevant stakeholders
- The CAB assesses risk, impact, timing, and rollback plan
- If approved, the change is scheduled for a change window (often off-hours)
- An execution plan and a rollback plan are documented before the change is made
- After the change, its success or failure is recorded, and lessons are fed back into the process
The goal is to prevent unplanned production incidents caused by unreviewed changes. The failure mode this protects against is: a sysadmin pushes a well-intentioned change on a Tuesday afternoon, something unexpected happens, and suddenly payroll cannot run.
If you are in a meeting with IT operations staff and someone says “we need stronger change management,” this is what they mean. The fix looks like: set up a ticketing system (OTOBO, ServiceNow, Jira Service Management, Freshservice, GLPI, or similar), define what needs to go through the CAB, and enforce it.
Crucially, ITIL change control is about production infrastructure. It is not about code or configuration in general — source control (Type 1) handles that. It is specifically about: should we apply this change to the production environment, now, and what happens if it goes wrong?
Type 3: Organizational Change Management (OCM)
And now the one everyone else — from the rest of the business — thinks of first. This is the kind of change management that the ERP-industry research keeps saying is the #1 reason major business-software projects fail. It is also the one software and IT people are least likely to think of when they hear the phrase.
Organizational Change Management (OCM) is about people, not systems. When an organization replaces its accounting system, reorganizes a department, rolls out a new expense policy, or adopts any new way of working, the technology side of that change is often the easier half. The harder half is the people side — getting users to accept the change, learn the new way, stop reverting to the old way, and actually produce the results that justified the investment.
OCM covers:
- Stakeholder mapping — identifying who is affected, who are the champions, who are the likely resistors, and who influences them
- Communication planning — what gets said to whom, when, through which channel, and by whom (the message from the CEO lands differently than the same message from a project manager)
- Impact assessment — for each role, what changes in their daily work on day one, day thirty, and day ninety
- Training programs — role-specific, hands-on, repeated, not one-and-done
- Resistance management — actively listening for objections and either addressing them or explaining why they are not being addressed
- Reinforcement — post-go-live work to keep people from silently reverting to the old system, workarounds, or shadow spreadsheets
None of this is technical work. All of it is the thing that gets left out of project plans, given to the most junior person, funded last, and cut first when the budget runs tight. And it is the thing that ERP, CRM, and HCM research names as the number-one cause of project failure, year after year.
If you are in a meeting where someone says “the change management on that project was awful, that is why it failed,” and they are not a software engineer or sysadmin, they almost certainly mean OCM. Not git. Not CABs. The people side.
Frameworks You Will Hear About
If you start paying attention to OCM conversations, two framework names come up repeatedly. You do not need to be an expert in either, but knowing what they are will save you from looking lost in a meeting.
Prosci ADKAR
Prosci is the dominant consultancy and certification body in the OCM world, and its ADKAR model is widely used. ADKAR is about individual change. It says people successfully adopt a change when they move through five stages:
- Awareness — they know a change is coming and why
- Desire — they want to participate (or at least do not actively oppose)
- Knowledge — they understand how to work in the new system
- Ability — they can actually do it under real working conditions
- Reinforcement — the new behavior sticks and does not revert
Skip any of those five and adoption stalls. The model is popular because it gives a concrete diagnostic: if adoption is stuck, which of the five is missing?
Kotter’s 8-Step Process
John Kotter’s 1996 book Leading Change introduced an eight-step process for organizational change from the leadership perspective:
- Establish a sense of urgency
- Build a guiding coalition
- Form a strategic vision
- Communicate the vision
- Empower action by removing barriers
- Create short-term wins
- Consolidate gains and produce more change
- Anchor new approaches in the culture
Kotter is more top-down than ADKAR; ADKAR works with people on the front line; the two are often used together.
If you have heard of ADKAR or Kotter, the subject is almost certainly OCM (Type 3). Nobody uses these frameworks for git or CABs.
How to Tell Which Type Is Being Discussed
Next time “change management” shows up in a meeting, you can usually tell which type is in play from small contextual clues:
| They say… | They probably mean… |
|---|---|
| “pull request”, “branch”, “merge”, “git”, “CI/CD”, “review” | Type 1 (source/config) |
| “RFC”, “CAB”, “change window”, “rollback plan”, “ITIL”, “ITSM”, “incident” | Type 2 (ITIL change control) |
| “adoption”, “training”, “stakeholders”, “resistance”, “users won’t”, “ADKAR”, “Kotter”, “communication plan”, “sponsor” | Type 3 (OCM) |
| They are talking about… | They probably mean… |
|---|---|
| A software release or deploy | Type 1 or Type 2 |
| A production system outage or risk | Type 2 |
| An ERP, CRM, HR, or process rollout | Type 3 |
| Employees, users, departments, behavior | Type 3 |
If you still cannot tell, the single most useful question to ask is: “Are we talking about code, about production systems, or about people?” You will get a clean answer.
Why This Confusion Actually Matters
It is tempting to treat all of this as harmless jargon drift, but the confusion has real costs.
When a software-first team hears “ERP failures are mostly change-management problems,” they hear “we need better RFCs or better git discipline.” They then solve the wrong problem. The ERP research is telling them the users did not adopt the system, management did not push them to, training was inadequate, and the workarounds won. Fixing the CAB process will not change any of that.
When a business-first team says “the technology works but change management failed,” and the IT team hears that as an accusation about ITIL process, the conversation derails. The business team meant OCM. They are not complaining about the CAB.
Vendors exploit the confusion. A vendor selling a digital adoption platform will happily describe their product as “change management software,” knowing that a software buyer and a business buyer will both feel validated by the phrase while having two different products in mind.
The simplest professional habit, when you work across disciplines, is to always qualify the term:
- “Source control” or “configuration management” for Type 1
- “Change control” for Type 2
- “Organizational Change Management” or “OCM” for Type 3
Reserve unqualified “change management” for the specific context where everyone in the room has already agreed which one is meant. When in doubt, spell it out.
Change Management and Software Platforms
Each of the three disciplines has its own software ecosystem, and they do not overlap.
For Type 1 (source/config), the tools are git, GitHub, GitLab, Bitbucket, and infrastructure-as-code platforms like Terraform, Ansible, and Pulumi. You will also hear about GitOps — the practice of driving infrastructure changes through the same pull-request workflow as application code.
For Type 2 (ITIL change control), the tools are IT Service Management (ITSM) platforms: OTOBO, ServiceNow, Jira Service Management, Freshservice, ManageEngine ServiceDesk Plus, GLPI, OTRS, Zammad, and others. Change control is one of several ITIL processes these platforms support, alongside incident management, problem management, and the rest.
For Type 3 (OCM), the tools divide into two camps. Digital Adoption Platforms (DAPs) like WalkMe, Whatfix, Pendo, Userlane, and Appcues sit on top of other applications and guide users through workflows in the real UI. OCM program platforms like Prosci Proxima, OCMS Portal, and The Change Compass support the programmatic side — stakeholder maps, readiness assessments, change portfolios, communication plans.
No tool covers all three disciplines. Anyone selling you a single platform for “all your change management needs” is almost certainly offering one of the three categories with optimistic marketing on the others.
Why You Might Need All Three
In a mature organization, the three disciplines are not alternatives. They are independent requirements that address completely different failure modes.
| Discipline | What it prevents |
|---|---|
| Source / config change management (git) | Undocumented drift, unreviewable changes, unrecoverable states |
| ITIL change control (CAB, RFCs) | Production incidents from unreviewed operational changes |
| Organizational Change Management (OCM) | Users rejecting or working around a new system or process |
A project that gets source control right but skips OCM goes live on time, under budget, technically correct — and is abandoned by its users within a year. A project that runs a beautiful OCM program but has no git-tracked configuration will rot within two years as changes stop being reviewable. A project that has both but no ITIL change control will eventually take production down on a Tuesday afternoon.
The three disciplines look almost nothing alike in practice. They are planned by different people, paid for out of different budgets, and measured in different ways. But if you are running a major change of any kind — and particularly a major software or business-process change — you will need all three, even if one of them is “we use git and pull requests and we all agree what that means.”
Closing Thought
In IT, ambiguous jargon usually resolves itself after a few missed conversations. “Change management” is different — the three meanings come from three professional communities that rarely talk to each other, and when a project needs all three at once (an ERP rollout being the classic case), the confusion stops being harmless and starts costing real money.
The fix is one clarifying question: Are we talking about code, production, or people? You will almost always get a useful answer — and the person you asked will often realize the rest of the room had no idea which one they meant either.
Ask it early — preferably before the project plan is written.