What is change management in IT — and is it the same thing in project management?

Change management in IT means controlling changes to systems that are already running: deciding what may be altered on a live server, network or application, by whom, when, with what testing and what way back if it fails. It is a discipline of production operations, codified in the British government's ITIL library in the late 1980s, and it is not the change management that trains people to work in a new way, nor the change control that governs scope on a project. Three separate disciplines share one phrase. The IT version protects the system from the change; the project version protects the plan from the change; the organizational version protects the change from the people. Most of the confusion in the field, and a fair share of its failures, comes from putting the wrong one of the three in charge of the question in front of it.

What is change control in IT — and what is a change advisory board?

Change control in IT is the procedure by which a proposed alteration to a production environment is recorded, assessed, approved, scheduled, carried out and reviewed. The vocabulary comes from ITIL, the Information Technology Infrastructure Library, written for the UK government's Central Computer and Telecommunications Agency and, through its 2000 and 2007 editions, the common language of corporate IT departments. In that language a change is any addition, modification or removal of anything that could affect a service; a request for change, the RFC, is the ticket that proposes one; and the change advisory board, the CAB, is the group that meets, often weekly, to approve, defer or refuse the queue.

ITIL sorts changes into three kinds. A standard change is pre-approved because it is routine and low-risk, a patch applied a hundred times before; it is logged but not debated. A normal change goes through the full assessment and the board. An emergency change cannot wait for the board, a fix during an outage, and is approved by a smaller group and reviewed afterward. The sorting exists to spend attention where the risk is. A department that puts every change in front of the board treats a font change the same as a database migration, and the board learns to wave both through.

What the board assesses is narrow and technical: what the change touches, what depends on it, whether it was tested, whether two changes on the same night collide, and whether there is a documented way to reverse it. None of this is about whether anyone wants the change. That was decided somewhere else. The board's question is whether the system will survive it.

What is change management in project management?

Change management in project management means change control on the project's own terms: a request to alter the scope, schedule, budget or requirements is written down, assessed for its impact on the other three, and approved or rejected by someone with the authority to spend the project's money. The Project Management Institute's PMBOK Guide calls the process Perform Integrated Change Control and gives the deciding body a name that is almost, but not quite, the IT one: the change control board, or CCB.

The near-collision of names is not an accident; both disciplines borrowed the idea from the engineering configuration management the US Department of Defense formalized in the 1960s. But the two boards judge different things. The project board asks whether a feature is worth four more weeks and the risk to the launch date. The IT board asks whether Thursday night's deployment of it will take the order system down. A project can clear every change through its CCB and still be stopped at the CAB, and a project manager who has never run a production system is routinely surprised to find that the quarter-end freeze and the tested rollback were never the project's to negotiate.

Project change control exists because of scope creep, the subject of an earlier post on why so many IT projects fail. Its enemy is the small reasonable request that nobody prices; its instrument is the form that forces a price onto it. It has nothing to say about whether the users will adopt the result or whether the servers will stay up.

Change management vs change control: are they the same thing?

Change management and change control are not the same thing, though IT departments use the words almost interchangeably. The cleanest way to hold the distinction is by what each one protects.

Change control, in either the IT or the project sense, protects a baseline: in IT the known configuration of the production environment, in project work the approved scope, schedule and budget. Nothing moves off the baseline without a record, an assessment and an authorization, so that at any moment someone can say what the system is supposed to look like and why it differs from last month.

Change management in the organizational sense protects an outcome. It assumes a decision has been made and works on the people who have to live with it: why the change is happening, what it asks of them, what training exists, and what happens to the resistance any imposed change produces. Its line runs from Kurt Lewin's work on group behavior in the 1940s through John Kotter's eight steps in the Harvard Business Review in 1995 to the ADKAR model that Prosci, the Colorado research firm founded in 1994, built from its surveys of practitioners. An earlier post on whether change management means layoffs covers that discipline and the fear attached to it.

The practical test is to ask what a failure would look like. An outage means IT change control. A project three months late and a million dollars over means project change control. A system that works perfectly and that nobody uses means organizational change management. A large implementation can fail all three ways at once, which is why it needs all three disciplines, and why assigning one person to "change management" without saying which kind is the first step toward failing in the other two.

Why is change management important in IT?

Change management is important in IT because almost every serious outage begins with a change, and the change that does the damage is seldom the one that was feared. Two documented cases carry most of what there is to know.

The first is Knight Capital. On the morning of August 1, 2012, the firm, then one of the largest traders of American equities, deployed new code to the eight servers that ran its order router. According to the order the Securities and Exchange Commission issued in October 2013, one technician did not copy the new code to one of the eight, no second technician reviewed the deployment, and Knight had no written procedure requiring that anyone do so. The eighth server still carried a routine called Power Peg, retired in 2003 but never removed. When the market opened, a flag in the new code reactivated the old routine on that one machine, which began sending orders without the check that would have told it to stop. In about 45 minutes Knight made more than four million executions in 154 stocks and lost more than $460 million. The SEC fined the firm $12 million.

Nothing in that story was a failure of technology; the new code worked on seven servers. It was a failure of change control in the strictest sense: a change deployed without verification that it had landed, without a second pair of eyes, and without a rollback anyone reached for.

The second case is larger. On July 19, 2024, the security firm CrowdStrike pushed a content update to its Falcon sensor, which runs inside the Windows kernel on a large share of the world's corporate computers. By the company's own root-cause analysis, the sensor expected a file with 20 input fields and the update supplied 21; the mismatch caused an out-of-bounds memory read and a crash on every machine that received it. Microsoft estimated that about 8.5 million Windows devices went down, and they could not be fixed remotely because they could not boot. In its remediation plan CrowdStrike committed to validate the number of fields, to roll such updates out in stages rather than to every customer at once, and to let customers choose when and where updates landed. Each is a control the organizational discipline has no word for and the project discipline would not have thought to ask about.

What the two cases share is that the change was small, routine, and approved by whoever was supposed to approve it. The failure was in the mechanics of the change itself, the part of the work that the IT discipline exists to govern and that the other two take for granted.

What does a change advisory board do — and does it work?

A change advisory board reviews proposed changes to production systems and approves or defers them, and the best evidence available says that as a control on risk it does not work. The evidence comes from DORA, DevOps Research and Assessment, the program under which Nicole Forsgren, Jez Humble and Gene Kim surveyed tens of thousands of technology workers and published the results annually as the State of DevOps report and, in 2018, as the book Accelerate.

They measured four things for each organization: how often it deployed, how long a change took from commit to production, how often a change caused a failure, and how long it took to restore service. Then they asked which practices separated the organizations that did well on all four from the ones that did badly. In Accelerate they reported that approval by an external body such as a change advisory board was negatively correlated with lead time, deployment frequency and time to restore, and had no correlation with the change failure rate. The 2019 report sharpened it: respondents whose organizations ran a formal approval process through an external board were 2.6 times more likely to be low performers, and the researchers found no evidence that the heavier process reduced the rate at which changes failed. Low performers that year reported that 46 to 60 percent of their changes caused a failure, against 0 to 15 percent for the elite group, and took between a month and six months to get a change into production against the elite group's one day.

The mechanism is not that review is useless. It is that a weekly board reviewing tickets written by people it does not work with cannot know enough about any one change to judge it, so it falls back on the proxies it can see: whether the form is complete, whether the date is inside a freeze window. Meanwhile the delay causes teams to batch their changes into larger and rarer releases, and larger releases fail more often and are harder to diagnose. The board slows the system down and, by slowing it, makes each change riskier. The recommendation was to move review closer to the work, to a peer who understands the change, backed by automated tests that reject a bad one before any human has to, and to keep the board for the few changes whose blast radius justifies it.

Neither Knight nor CrowdStrike would have been saved by a weekly meeting; both would have been saved by a second person looking at the specific change and a rollout that reached one machine before it reached all of them.

Change management vs change enablement: why ITIL renamed it

ITIL renamed change management to change enablement in its fourth edition, published in 2019, and the renaming is the discipline's own acknowledgment of the DORA finding. ITIL 4 kept the three categories of change and the idea of a change authority, but dropped the assumption that the authority is a central board: it should sit wherever the knowledge is, with the team that owns the system, often a peer rather than a committee, increasingly in software rather than a meeting. Enablement says the practice exists to make change safe and frequent, not rare.

The rename matters because the two names mark two philosophies. A department that still speaks of change management, meets as a board on Tuesdays and counts its success in changes prevented is running the 2007 model. A department that speaks of change enablement, approves most changes automatically on the strength of tests, and measures its change failure rate and time to restore is running the 2019 one. The second deploys more often and breaks less, which is the opposite of what the first department's intuition says, and the intuition is why the first is still common.

There is a fourth sense, the one an auditor tests. Since the Sarbanes-Oxley Act of 2002, change management has been one of the IT general controls auditors examine on the systems that produce a public company's financial numbers: that every change was approved by someone other than its author, tested, and recorded, and that the people who write code cannot move it into production alone. An auditor used to a signed form for every change has to be shown that an automated pipeline, with its test results and deployment log, is the stronger control.

What happens when the three meanings meet on one project

The three meanings meet on every large system implementation, and what goes wrong is consistent enough to describe in advance. Take a company replacing the system its operations staff have used for fifteen years. The project's change control board does its job: scope is held, late requests are priced, the launch date moves twice and both moves are documented. The IT change advisory board does its job: the cutover is scheduled outside the quarter-end freeze, the rollback is reviewed, the old system is kept warm for thirty days. A change manager has run the communications and the training, and the completion rate on the dashboard is 96 percent.

Then the system goes live, and the staff keep the old spreadsheets. They enter each transaction in the new system because they must and check it against the spreadsheet because they do not trust it yet, the double-keying that David Luria describes in Flatten the AI J-Curve as the mechanism behind the productivity dip of every new system: for a period the staff do two jobs. Throughput falls. The error rate looks high, because every discrepancy is logged against the new system whether or not it was wrong. By the third month, the point Luria calls the kill zone, the operations director is asking for the old system back and has the numbers to make the case.

Now watch which board the problem goes to. It goes to the project's board, because the project is still open, and that board does what it is built to do: it prices a request to extend parallel running by ninety days and to add the spreadsheet's three missing fields. Both are approved. Neither addresses the problem, which is that the staff were trained on the system and not on the decision to trust it, and that nobody owning the organizational change is in the room, because that engagement ended at go-live. The IT board sees a request to extend the life of a system it had scheduled to decommission and refuses it, because two systems of record is a control failure, which it is. Each board has answered the question it exists to answer. The project fails anyway, in the one way none of the three was watching.

The fix is not a fourth board. It is a statement, written before the project starts, of which failure each discipline owns and what evidence would show it beginning. IT owns the outage and watches change failure rate and time to restore. The project owns the overrun and watches scope and schedule. The organizational discipline owns non-adoption and watches the measure the dashboard did not show, whether the staff have stopped checking the spreadsheet, and it stays in the room until they have. The earlier post on why AI projects stall after the pilot describes the same pattern with a different technology; the boards do not change, and neither does the gap between them.

What is the purpose of change management in IT, then?

The purpose of change management in IT is to make change safe enough to do often. That is the whole of the modern discipline, and the reverse of what the phrase meant for twenty years, when the board's measure of success was the number of changes it had stopped. The evidence, from the DORA surveys and the public record of the outages, points one way: the organizations that change their systems most often are the ones whose systems fail least, because small frequent changes are easier to test, review, roll back and diagnose than rare large ones, and because the mechanics of changing safely, the second pair of eyes, the staged rollout, the tested way back, become habits only when exercised every day.

For someone meeting the phrase for the first time, three questions sort it. Ask what would fail: a system, a plan or an adoption. Ask who approves: a weekly board, a sponsor with a budget, or a peer who knows the code. Ask what gets measured: change failure rate and time to restore, scope and schedule, or whether people have stopped using the old way. The answers tell you which discipline you are looking at and, more usefully, which two are missing. In the Chicago tower the levers were interlocked so that no two conflicting routes could be set at once, and a man at a desk wrote down every order and every movement as it was made. The frame was the control. The ledger was the proof. An IT department that has both is doing change management in the sense that matters, whatever it calls it.

One email when a book ships. Nothing between.

← All posts