When should you implement change management — and does every project need it?

Change management should be implemented on the day a project is approved, before the first requirement is written, and on any project that changes how people do their work. It is not a phase that follows the build, nor a communications plan added when the resistance arrives. The surveys, the field studies and the economics point the same way: the earlier the work of preparing people begins, the more often the project meets its objectives, and the later it begins, the more it costs to buy back the same result. The exception is a change that alters no one's work, a like-for-like hardware swap, and those are rarer than the plan says. Implementing it is deciding to treat the people who will do the work as part of the system being built, a decision that is cheap at approval and expensive at go-live.

When is change management needed — and when is it not?

Change management is needed whenever a project's benefit depends on people doing something differently afterward. That is the whole test. A new ledger that posts the same entries the old one did, keyed by the same clerks in the same order, needs testing and a cutover plan, not change management. A new ledger that asks the clerks to stop keeping the spreadsheet they trust and to be measured on a number they did not choose needs change management, whatever the vendor calls the product.

Paul Lawrence made the distinction in the Harvard Business Review in 1954, in an article covered in an earlier post on managing resistance in the workplace: people rarely resist the technical change, they resist the social change that rides along with it, the alteration in whose judgment counts. The test for whether change management is needed is therefore a test for social change. If the project alters who decides, who checks, who is consulted or how performance is seen, it needs the discipline. If it alters only which screen the same decision is made on, it may not.

The failure runs in both directions. Projects that need the discipline skip it because the technology looks simple, and the simplest-looking technology, a form that moves online, often removes a job someone was proud of. Projects that do not need it get a full program anyway, because a methodology was bought and must be seen to run. Kotter and Schlesinger's 1979 advice applies: size the effort to the situation, not to the template. A change nobody will notice does not need a narrative. A change that takes a skill from a hundred people needs more than one.

When should change management start: before the project or after the go-live?

Before the project, and the evidence on this is as consistent as anything in the field. Prosci, the research and training firm whose benchmark study is the largest practitioner survey in the discipline, has asked participants in each edition when change management started on their projects and whether the projects met their objectives. Its summary is that the earlier change management begins, the more likely the project is to meet or exceed its objectives, with the strongest results for projects that started at initiation; the firm publishes the direction rather than the percentages. The same study, across more than 2,600 practitioners in its latest edition, reports that 88 percent of projects with what participants rated as excellent change management met or exceeded objectives, against 73 percent for good, 39 percent for fair and 13 percent for poor, the spread that produces the firm's much-quoted figure of roughly seven times. Two caveats belong next to those numbers: they are self-reported by practitioners rating their own work, and they are correlations, since a well-run project may both start early and meet its objectives because it is well run. Neither reverses the direction.

The reason early beats late is not mysterious. Kurt Lewin's 1947 model, the oldest in the field, put a stage before the change, which he called unfreezing: the period in which the people who will change come to see that the present state cannot hold. That stage cannot be compressed later, because it is the time in which people stop defending the old way. John Kotter's 1995 Harvard Business Review article, "Leading Change: Why Transformation Efforts Fail," made the same point as its first error: most efforts fail at the start, by not establishing enough urgency before the work begins, and he added the line that has outlived the rest of the article, that skipping steps creates only the illusion of speed. A project that starts change management at go-live has not saved the unfreezing. It has deferred it to the moment it is most expensive, with the system live and the old way still available.

William Bridges, in Managing Transitions (1991), put a name on what the late start misses. Every change begins, for the people in it, with an ending, and the ending starts the day the change is announced, not the day it is installed. The months between are when people decide, mostly in private, what the change will take from them and whether they will give it. A project that spends those months on configuration arrives at go-live to find the decisions already made.

How does change management work when you start it late?

It works as repair rather than prevention, and the first move is diagnosis. Prosci's own guidance for the late start, which it describes as the common case where the discipline is "added on to a project after it is well underway," usually in response to resistance, is to find out what has already happened before planning anything: which groups were told what, by whom, when, and what they concluded. That order matters because a late effort that opens with a communications campaign tells the organization the project team has decided the problem is a messaging problem. People who have spent four months concluding that the new system will cost them their best skill hear a brochure.

Lawrence's 1954 article carries the second move. Where the resistance is to the social change, the repair is in the social design: who is consulted, whose knowledge counts, who gets to say what is wrong. The classic field experiment, Lester Coch and John French's 1948 study at the Harwood pajama factory, found that groups who took part in designing a change in their work methods recovered their output quickly, while a group given the same change by announcement did not recover and lost members. Started late, participation is still the strongest tool available, with the difference that the people now invited have already been excluded once and know it. The invitation has to carry something real: a design change the floor can see, or a decision about sequencing or training that is theirs.

The third move is to stop pretending about the schedule. A late start usually means the go-live date was set before anyone measured how long the people side would take, and the most common response is to hold the date and compress the preparation. Michael Beer, Russell Eisenstat and Bert Spector, in a 1990 Harvard Business Review study of six large companies, called the result the fallacy of programmatic change: the belief that a program announced from the center, with training and communications attached, produces changed behavior on a schedule. It did not in their six companies; the units that changed were those where line managers redesigned roles around real work, on a timeline the work dictated. The honest late-start plan moves the date, narrows the first release, or accepts longer double running. It does not add a change manager and keep everything else.

Change management timeline: what a realistic time frame looks like

The realistic time frame runs from approval to the point where the new way of working is the only way, and the second half of that is longer than the first. The build has a schedule; the adoption has a curve. Everett Rogers's work on the diffusion of innovations, first published in 1962, described the curve every adoption follows: a small group adopts early, a larger group follows once the early group has shown it works, and a last group changes only when the old way is removed. The curve is S-shaped, and its middle is where the time goes. A timeline that ends at go-live has planned for the first group.

Harold Sirkin, Perry Keenan and Alan Jackson, in "The Hard Side of Change Management" in the Harvard Business Review in 2005, drew on a Boston Consulting Group study of 225 companies and found something that cuts against the usual schedule logic: the duration that predicted failure was not the length of the project but the interval between formal reviews. A long project reviewed often did better than a short one reviewed rarely, and reviews more than a couple of months apart put the project at risk. The timeline therefore needs milestones on the people side as well as the build side: dates by which a named group will have used the system on real work, with someone senior scheduled to look.

A realistic time frame also carries the dip. Paul David's 1990 paper "The Dynamo and the Computer" traced how long it took American factories to get productivity from electric motors: decades, because the gains came only once factories were rebuilt around the new power source rather than wired for it. Erik Brynjolfsson and Lorin Hitt, in the Journal of Economic Perspectives in 2000, found the same shape in computing: the returns followed organizational investments in process redesign and training that took years and showed up nowhere on the balance sheet. Brynjolfsson, Daniel Rock and Chad Syverson formalized it in 2021 as the productivity J-curve, in which measured output falls while an organization builds the intangible assets that later pay. A timeline that ends at go-live has stopped at the bottom of the J.

When to use change management vs change control

Use change control when the thing changing is a system, and change management when the thing changing is a person's work. The two share a name and little else, a confusion covered in an earlier post on what change management means in IT. Change control, in the ITIL sense, decides whether and when a change may be made to a live system: it classifies changes as standard, normal or emergency, routes the normal ones through an authority, and exists to keep the lights on. It starts the moment a system is in production.

Change management, in the organizational sense, prepares people to work differently, and it starts earlier, at approval, because its work is mostly done before the system exists. Which to use is a question of which object is changing, and the trap is the project that runs one and believes it has run the other. A release that cleared the change advisory board and passed into production on a Friday can still be a failed change on Monday, when the people it was built for keep the old spreadsheet open beside it. The board approved the change to the system. Nobody approved the change to the work.

What does it cost to implement change management too late?

The cost is paid three times: in schedule, in benefit and in the next project. The schedule cost is the most visible. A project that discovers at user-acceptance testing that the users will not accept it has to add the months of preparation it skipped, with the system now built, so the design changes participation would have produced for free now cost rework. Prosci lists the symptoms of the late start as missed milestones, budget overruns and resistance, the same list as the symptoms of a failing project, because that is what a late start has become. An earlier post on why IT projects fail found the same pattern from the other side: the failures were rarely technical, and the sponsor and the users went missing before the technology did.

The benefit cost is larger and less visible, because it never appears as a line. A system that is live but routed around delivers the cost of the system and the cost of the old way at once, the double running that an earlier post on why AI projects stall after the pilot found behind most stalled rollouts. The business case counted the benefit of the new way; the organization is paying for both. An early change effort would have found the workaround, the shadow process that Flatten the AI J-Curve tells its readers to map in the first four weeks by interviewing the people who do the work rather than their managers. Started late, the workaround is discovered when the benefit fails to arrive, by which time it is the way the work is done.

The third cost is the one Albert Hirschman named in 1970: a project that teaches people their objections do not matter until it is too late for them to matter teaches them not to object next time. The late-start project does this efficiently: it asks the floor for its views at the point where they cannot change the design, and the floor draws the obvious conclusion. The next project starts in a building where the knowledge sits silent, and the one after that is called a culture problem.

When to implement change management on an AI project

On an AI project, change management starts before the pilot, and the first deliverable is a prediction of the dip. That is the central argument of Flatten the AI J-Curve, David Luria's book on enterprise AI adoption published this year, and it reverses the usual order. The usual order runs a pilot, rolls out, and brings in the people work when throughput falls. The book's order puts an audit and a J-curve presentation in the first four weeks, before any pilot starts: map the target process by interviewing the people who do the work, document the workarounds, calculate the expected depth and length of the productivity dip, and present the forecast to the board at month zero so that when month four arrives and the numbers are down, the sentence available is "as predicted" rather than "we are working on it."

The reason the order has to be reversed on AI projects in particular is the size of the dip. The book cites a 2025 study by researchers from MIT, the University of Colorado Boulder, the U.S. Census Bureau and Stanford, using two waves of Census surveys of tens of thousands of manufacturing firms between 2017 and 2021, which found that AI adoption reduced productivity by an average of 1.33 percentage points in the short term, before the gains. The book's own observation is that the drop is driven by double-keying: the star processor who runs the AI's output against her own work for months because nobody told her the dip was coming. That is a change management failure with a technical face, and it is prevented only before the pilot, because the person doing the double-keying decided to do it the week she saw the demo.

The book's second timing rule is about the budget. Six-month pilots die in what it calls the Kill Zone, because the budget runs out in month six and breakeven comes in month nine; its advice is to lock in eighteen months of funding before the pilot and to tell the board that the result will not be known before month twelve. That is change management for the executives, implemented at approval, and it is the same discipline as unfreezing a shop floor: the people who will have to hold their nerve are prepared for what they will see before they see it. A board that was not prepared behaves like any other group given a change by announcement.

So when do you implement change management?

At approval, on every project that changes how someone works, and with the first month spent finding out what the work actually is. The sequence the evidence supports is short. At approval, decide whether the project changes anyone's work; if it does, the change effort is part of the project, with a name, a budget and a share of the schedule. In the first weeks, map the work as it is done, not as it is documented, and let what the people who do it say change the design while changing it is cheap. Set the date from the adoption curve, not the build plan, with review points on the people side close enough together that drift is caught small. Forecast the dip and tell the people who will see it, including the board, before it arrives. Then hold the date against the forecast, not the panic.

A surveyor running lines for a tunnel in Utah in 1942 was working on a steel mill that did not exist, and the lines he ran decided where the walls could go. Change management is that survey. It is done on open ground, before the build, and it is the cheapest work on the project, because it costs stakes and string and the only thing it moves is a plan. Done after the walls are up, it costs walls.

One email when a book ships. Nothing between.

← All posts