Have you ever faced a change initiative that did not go the way you planned?
A project intended to simplify operations ended up making them more complex. A new technology that promised greater efficiency created parallel processes instead. Or a technically sound transformation met so much resistance that the change initiative itself had to be reconsidered during implementation.
If this has happened to you, you have probably asked yourself a difficult question: what went wrong?
Sometimes the answer seems to lie in the design. But not always. A transformation can begin with a solid diagnosis, use the right methodologies, and even arrive at an excellent solution, yet still lose a significant part of its value when the time comes to turn that solution into reality.
The Diagnosis and the Illusion of the Perfect Solution
Several years ago, I faced a case that illustrates this problem very well.
The company was losing money, and the explanation seemed obvious: competition had become more aggressive. It was a chain of apparel and sporting goods stores owned by a larger business group. For years, it had operated relatively independently and had gradually fallen behind more modern retail practices.
But when we looked more deeply at the data, competition turned out to be only part of the story.
Some stores had far more space than their sales could economically justify, creating costs that were difficult to recover. There was excess inventory and, paradoxically, products customers wanted to buy but could not find. Sales associates faced thousands of SKUs and could not possibly know everything that was available, the possible substitutes, or what inventory existed at other stores. Information did not flow effectively between the stores and Purchasing either. On top of that, the company had outdated technology, assortment and inventory management practices that needed to be modernized, and capabilities that had been sufficient for the historical operating model but were not necessarily enough to compete under a new one.
We did not find one problem. We found a perfect storm.
The diagnosis allowed us to build an integrated transformation. We incorporated retail best practices, redesigned processes, proposed organizational changes, developed new capabilities, introduced better technology, and defined metrics to track results. The solution made sense and addressed the root causes we had identified.
Improving the Boxes, Neglecting the Arrows
Then implementation began.
And something interesting happened: while each function moved forward with its part, the transformation as a system began to weaken. Purchasing worked on Purchasing, Retail focused on the stores, Technology developed tools, and Human Resources addressed capabilities. There were meetings, deliverables, and visible progress. Viewed individually, many things were happening correctly.
“The problem was that we were improving the boxes while neglecting the arrows.”
A company does not operate as a collection of independent departments. Information, decisions, exceptions, and responsibilities flow among Purchasing, Sales, Operations, Finance, and Technology. When those interfaces are not properly designed, every handoff can introduce delays, reinterpretation, rework, or loss of information. That is why an organization can have efficient processes and, at the same time, a deeply inefficient system.
The Silent Erosion of the Design
Then another, much quieter phenomenon appeared. The transformation began competing with day-to-day operations. And day-to-day operations almost always win.
Some of the people responsible for implementing the changes had not participated directly in the original design and, at the same time, still had to handle their regular responsibilities. Small, perfectly understandable decisions began to appear: we can leave this for later; for now, let's use Excel; that integration can wait; perhaps we do not need all that training.
None of those decisions destroyed the project. But together, they began to transform it.
I call this the silent erosion of the design: the project officially remains alive, everyone continues talking about the same transformation, but the solution ultimately being implemented is no longer exactly the one that justified the investment.
And that raises an uncomfortable question: at what point did we stop implementing the original project?
That moment probably never existed. No one gathered the team and decided to abandon the design. It simply faded, piece by piece.
There was also a governance problem. A transformation that cuts across Purchasing, Commercial, Technology, Human Resources, Operations, and Finance needs authority that matches its scope. It is unreasonable to hold one function accountable for changes that depend on several others over which it has no authority. You cannot assign cross-functional accountability using only functional authority.
Transforming the Business or Simply Completing the Schedule?
Does that mean the project failed? Not necessarily. Improvements were made, and the company could end up operating better than before. But that is not the question that should determine whether a transformation was successful.
The right question is: did the benefits that justified the transformation actually materialize?
Fewer lost sales, higher margins, better sales per square foot, lower inventory, faster inventory turns, lower costs, and greater profitability. Installing technology, redesigning stores, training people, or completing a project schedule are important milestones, but they are not the benefit. That is the difference between implementing a project and transforming a company.
Over time, the most important conclusion was realizing that there had never been a single solution. There was a system of solutions. Best practices, processes, interfaces, people, technology, organization, governance, and implementation discipline all had to work together. The value was not only in each component, but in the way all of them interacted.
Because designing a transformation and making it happen are two different disciplines.
Transforming a company is not simply about designing how it should operate. It is about making it operate that way and proving that the change produced the value that justified it in the first place.
The Takeaway
After investing so much effort and getting so little in return, do you feel stuck?
Few things are more frustrating than trying to improve an organization only to discover that the change is not producing the expected results, that operations have become even more complex, or that the benefits eventually arrive but at a much higher cost than anticipated.
When that happens, doing more of the same rarely solves the problem. Sometimes you have to stop and ask whether you are changing the right things, whether you are changing them as an integrated system, and, above all, whether the organization is actually operating under the new model.
Do you need help? Find it.
Because a transformation should not be measured by how much effort it required, but by how much value it actually turned into reality.
* Case inspired by real-world experiences. Industry, circumstances, and data have been modified to preserve confidentiality.