Why process change dies in the middle

A packaging manufacturer, 480 people, four plants, a mid-size Brazilian company (figures in Brazilian reais). Leadership contracted a new order-management system in March. There was a launch meeting, training in two groups, a memo with the word transformation in it. By September, three of the four plants had gone back to running on the old spreadsheet, and the system had become a report filled in at month's end so headquarters wouldn't complain.

No one sabotaged anything. Every person who went back to the spreadsheet had a concrete reason that day: an urgent order, a field that didn't exist, a customer waiting on the phone. The sum of those reasons is what's usually called resistance to change — and the label hides what actually happened, which is a poorly sequenced rollout.

01The idea: transformation is sequence, not announcement #

John Kotter published Leading Change: Why Transformation Efforts Fail in the Harvard Business Review in 1995, expanded into the book Leading Change the following year. The material came from observing transformation efforts in organizations he'd followed over the previous decade. Kotter argued, based on that observation, that most of those initiatives failed to deliver what they promised.

It's worth noting what that claim is and isn't: the author's reading of the cases he studied, not an index measured on a representative sample. The number that circulates in corporate presentations as if it were a universal change-failure statistic doesn't come from that source — and repeating it as data is exactly the kind of thing this blog doesn't do. The value of Kotter's work isn't in the percentage; it's in the diagnosis of the sequence.

The eight steps, in the order he presents them: establish a sense of urgency; form a coalition with enough power; create a vision and the strategy to get there; communicate that vision relentlessly; remove the obstacles that stop people from acting on it; produce short-term wins; consolidate gains instead of declaring victory too soon; and anchor the new behavior in the culture.

Kotter didn't invent the concern. Kurt Lewin had already described, in 1947, that an organizational state is held in place by a balance of forces and that change requires unsettling that balance before refreezing it at another point. And Everett Rogers, in Diffusion of Innovations (1962), showed that adoption of any novelty spreads through groups with differing readiness, not all at once. The three readings converge: rolling out a change is not a single-date event.

02Why it still holds up for system rollouts #

The 1995 text talked about restructuring and total quality. The translation to a system rollout is almost literal, because the real object of change is the same: the way people do their work every day.

Urgency, in the case of a system, isn't leadership's speech about competitiveness. It's an operations person being able to say, in their own words, which of their problems it solves. If the honest answer is none, the urgency belongs to leadership, not to them — and adoption will depend on constant policing.

A coalition isn't a project committee. It's having, in each area that will use it, someone with recognized informal authority who already uses the tool and answers questions the same day. Without that, the mid-afternoon question finds the old spreadsheet as the fastest answer.

And removing obstacles is the step that almost always falls off the schedule. As long as the official report keeps being accepted in the old format, the old format remains mandatory in practice. Prolonged coexistence of two paths isn't a smooth transition: it's doubling the workload of whoever executes it and letting them choose the shorter one.

03The cost of the system left half-finished #

At the scale of the 480-person manufacturer, with 120 expected users. Stated assumptions for you to rework with your own numbers:

Want to see how this looks inside a real operation? Explore the platform.

The math: 35 minutes × 220 working days gives about 128 hours per person a year; across 45 people, 5,800 hours of duplication, plus the time spent by whoever consolidates and reconciles the two sources at closing, which in the example company added another 2,400. The annual license, in that scenario, tends to be the smallest line in the tally — and it's the only one that shows up in the budget discussion.

There's also a cost that never appears in any spreadsheet: the next rollout. A company that abandoned a system halfway learns that these projects cool off, and adoption starts lower the next time around.

04Where this gets stuck in practice #

1. The urgency belongs to leadership. Whoever operates the process never heard which of their pains the project solves, and the project becomes just another head-office demand.
2. The sponsor disappears after launch. Their presence lasts through the kickoff photo; from then on, the project team negotiates alone with each area.
3. The old path stays open. As long as the spreadsheet is accepted, it wins — because it's faster for whoever has a customer on the phone.
4. There's no short-term win. The first visible result is promised for year-end, and the team's energy runs out by July.
5. Victory gets declared too early. The project closes at go-live, the team gets reassigned, and no one stays responsible for fixing what shows up in month three.
6. Nothing changes in the management ritual. The weekly meeting still asks for the number from the old spreadsheet, and that communicates more than any training.

05What data-driven management answers #

A rollout only survives when the new way is easier than the old one on the day the customer is waiting. That's a design decision, not a discipline one: fewer required fields, entry happening inside the work instead of after it, and progress visible without anyone having to build a report.

It's also where adoption stops being a matter of opinion. How many areas record in the new source, how long it takes from request to first step, how many exceptions still slip outside the process — these are measures that exist once the process lives in the system instead of in conversation. Before any of that, the order described in automating a bad process only speeds up the error matters: fix the flow first. And what sustains the new behavior in the long run is what's described in the three levels of culture, with the link between objective and verification described in from MBO to OKR and the category explained in what is Collaborative Work Management.

At Relevanti, this shows up in the process, operations, and automation modules of the platform, with the breakdown by area in solutions. If you already have a project stuck halfway, a conversation usually pinpoints which step it stalled on.

Change that depends on people remembering to do things differently already has an expiration date. The kind that lasts is the kind that changes the shortest path.