A transformation can spend two years becoming safer on paper without changing a single real thing. The target architecture gets better. The roadmap becomes more detailed. Risks are documented, exceptions are discussed, another workshop is scheduled, and another presentation is prepared for management.
Meanwhile, the old systems are still running exactly as before. At some point, the problem is no longer that the transformation is risky. The problem is that it still hasn't started.
We Want Certainty Before We Start
I understand where this comes from. Large organizations cannot simply switch off an old system and say, "let's see what happens." There are customers, payments, invoices, data, regulations and processes that cannot stop just because somebody drew a better architecture. We need management approval, a migration plan, clear ownership, security decisions and answers to many difficult questions.
The problem begins when we try to answer every possible question before we take the first real step. The new system needs to support every product, every country, every process, every exception and every historical behavior of the old solution. If we find one case we cannot solve yet, we postpone the start and go back to analysis. Then we find another one, and another. Eventually, the requirements for the first step begin to look almost the same as the requirements for the finished transformation.
Some Problems Will Never Appear In A Workshop
You can spend months analyzing a process and then move the first hundred customers to a new solution and discover things within a few days that nobody predicted. Not because the analysis was poor. The real system is simply more complicated than its description.
Documentation does not capture every user behavior. A diagram does not show every organizational dependency. A process slide does not include the person who has been manually correcting a file once a month for six years and no longer even thinks of it as an exception. Some knowledge lives in people's heads, and some has been buried in systems for so long that nobody remembers why it exists. Only when we start changing the real process do these things begin to surface.
Implementation Does Not Start After Learning Ends
Large programs often try to organize work into a very logical sequence: analyze everything, design everything, build it, test it and finally migrate. The problem is that knowledge in complex organizations rarely appears in such a clean order.
During implementation, we discover things we missed in analysis. During the first migration, we discover problems that implementation did not reveal. After the first real process goes live, we learn things the test environment never showed us. That does not always mean somebody did poor work earlier. Sometimes it simply means that we have finally started working with reality instead of a model of it.
Transformation itself is part of the learning process. If we try to acquire all of that knowledge before starting the change, we may wait for a very long time.
We May Have Forgotten What Agile Was For
Sometimes I feel that many organizations kept the ceremonies of Agile but lost one of its most important ideas. We have sprints, dailies, refinements, plannings and retrospectives, while at the same time a large transformation program is still planned several years ahead with a level of precision we will never be able to maintain.
One of the simplest ideas behind an agile approach is to take a meaningful step, observe the result, learn something and use that knowledge in the next step. This is not about having no plan. It is about accepting that the plan should change as our knowledge changes.
If we create a three-year transformation roadmap today, we should remember that before we reach the end, the people responsible for the project may change, management may change, the company strategy may change, products may change, vendor pricing may change, technology may change and the market may change. The problem that justified an architectural decision today may not even exist two years from now.
A plan should give us direction. It should not become a commitment to execute a decision three years later based on what we knew today.
We Need The First Real Change
I increasingly believe that good transformations start by finding the smallest part that can be changed for real. Not another POC running next to the existing world and serving no real process. Something small enough to keep the risk under control, but real enough for the organization to learn from it.
It could be one product, one sales channel, one type of customer, one country or one part of a process. Then theory finally meets reality. We learn whether the integration is actually enough, whether the data model handles real cases, whether users understand the new process, whether support can help the customer and whether billing behaves the way we expected. Those are things another month of design may never tell us.
A Problem After The Start Is Not Always A Failure
This is one of the harder parts of large transformations. Organizations often want the start of implementation to mark the end of surprises. When the first real rollout exposes a problem, the natural reaction is: "Why didn't we find this earlier?"
Sometimes we should have. But not always. If the first real process reveals five exceptions we did not know about, we now have five new pieces of information. We can improve the solution, change the process or consciously decide that an old exception should no longer be supported. That is progress.
I would be much more worried about an organization that discovered no new problems for two years simply because it did not actually change anything for those two years.
Standing Still Has A Risk Too
Transformation programs spend a lot of time discussing the risk of change: migration risk, data risk, customer impact, integration failures and business continuity. We talk much less about the risk of changing nothing for another two years.
The old system still needs maintenance. New integrations appear. New exceptions are added. More processes become dependent on something we are supposedly about to retire. People continue investing time in learning a platform the organization says it wants to remove. Paradoxically, the longer we prepare for the transformation, the harder the transformation itself can become.
It is possible to spend a very long time being officially "in transformation" without making any meaningful change at all.
Final Thoughts
I do not think we should stop planning. In a large organization, that would simply be irresponsible. But we need to recognize the point where more planning stops reducing risk. Another diagram no longer gives us new information. Another workshop repeats the same conversation. Another version of the target architecture moves a few arrows without changing reality.
At that point, something much harder remains: start. Take a small step, limit the risk, keep the ability to change direction and accept that along the way we will discover things we do not know today.
You cannot understand the entire transformation before you start it. Some of it only becomes visible once you begin changing reality.