The Transformation Factory - Managing Change Across Multiple Timelines and Perspectives
The roadmap stays stable while the transformation changes underneath it
Large transformations usually begin with a surprisingly simple description. A legacy platform will be replaced. A standard solution will be implemented. Applications will move to a new architecture. Product data will be consolidated. Customer processes will become digital. These descriptions are useful because they give the organization something it can name, fund, organize, and govern. A program is established, teams are formed, responsibilities are assigned, and a roadmap describes how the change is expected to unfold.
For a while, this picture appears to hold. Then the work starts revealing the system underneath it. The replacement discovers data that cannot be migrated cleanly. The standard solution does not support several capabilities that the business considers essential. The new architecture requires enabling services that do not yet exist. Refactoring exposes dependencies that were never documented. Temporary integrations become necessary to keep old and new solutions working together. Decommissioning turns out not to be a technical switch-off, but a long transition involving users, interfaces, products, operations, and ownership.
Nothing particularly unusual has happened. The organization has simply learned more about what it is trying to change.
The difficulty is that the transformation model surrounding the work often does not learn at the same speed.
A roadmap may continue showing one transformation while the organization is now actually dealing with several different forms of change. The administrative structure remains stable: one program, one budget, one steering committee, one headline objective. Underneath it, however, the work has begun to behave according to very different rules.
One program can contain several transformations
A transformation program is a useful container, but it should not be confused with the nature of the work inside it. A single program can simultaneously contain replacement, refactoring, replatforming, enabling, migration, standard implementation, and decommissioning.
One part of the landscape may be implementing a standard platform while another is restructuring an existing application. A third may be creating common services required by both. Data may require its own remediation and migration path, while legacy applications remain operational until customers, countries, or product families have moved. From the portfolio level, all of this may still be described as one transformation. Structurally,
it is not one kind of transformation.
That distinction matters because different transformation archetypes create different conditions for progress. Replacement depends heavily on migration, coexistence, operational readiness, and the ability to stop using what came before. Refactoring depends on understanding enough of the existing structure to change it without damaging what must remain. Replatforming changes the technological foundation while attempting to preserve required behaviour. Enabling work can absorb significant capacity without creating immediate visible business value because its purpose is to make later work possible.
Standard implementation creates another kind of tension altogether: the organization must distinguish between genuine business requirements and historical practices that have simply become familiar.
These differences influence what evidence matters, which decisions must be made, where risk accumulates, which skills become constraints, and what progress actually means. Yet transformations are frequently governed as though all of this work were structurally equivalent. The same milestones, planning assumptions, reporting logic, and definitions of progress are applied to work that behaves very differently.
Administrative consistency is useful. Structural uniformity is not. The problem becomes more difficult because the work does not necessarily remain in the archetype where it started.
The transformation creates knowledge that changes the transformation
A standard implementation may begin with the assumption that most of the required capability can be configured. Once the organization starts working through real business needs, it discovers that important functions are not supported. What started as implementation may now include custom development or replacement.
A refactoring effort may initially appear economically sensible because the organization expects to improve an existing solution incrementally. Once deeper architectural coupling becomes visible, the calculation changes. Continued restructuring may cost more and create more risk than partial replacement.
A replacement may initially assume a relatively clean transition from old to new. Later, the organization discovers that different customers, markets, products, integrations, and operational processes need to move at different times. The transformation now includes coexistence, synchronization, temporary interfaces, staged migration, and eventual decommissioning.
The original work has not simply become larger. It has changed shape. Systems thinking helps explain why this is normal. Meadows describes system behaviour as emerging from structures, relationships, feedback, and delays that are not always visible from outside the system. [1] Sterman's work on dynamic complexity similarly shows why interventions can reveal delayed or indirect consequences that were difficult to understand at the starting point. [2] Transformation is therefore unusual in one important respect: it creates knowledge about the system by changing the system itself.
That creates a difficult tension for leadership. The organization often wants the greatest certainty at the moment where it has the least knowledge. The business case, target architecture, roadmap, funding model, and delivery structure are established before much of the transformation learning has occurred. Once approved, those early assumptions begin to harden into governance.
Then the transformation begins discovering reality. The problem is not that the plan was necessarily wrong. Some knowledge simply did not exist when the plan was created. The problem appears when the organization treats the original description of the transformation as permanent even after the underlying conditions have changed.
More governance does not correct the wrong model
Transformations rarely announce that they have changed type. There is usually no formal moment when somebody declares that a standard implementation has become a replacement problem or that a technical migration has become an organizational transition. The change appears through symptoms.
Architecture exceptions increase. Temporary integrations multiply. Migration grows from a supporting task into a major work stream. Testing expands because the actual change surface is larger than expected. Teams become increasingly dependent on decisions outside their authority. Decommissioning slips because nobody can demonstrate that the old capability is no longer required.
The work changes while the roadmap often remains almost identical. This is where organizations tend to respond with more management. Plans become more detailed. Dependencies are tracked more aggressively. Coordination meetings multiply. Estimates are challenged. Reporting becomes more frequent. Teams are asked to recover the original milestone.
Those actions can be useful when the problem is ordinary execution. They are far less useful when the nature of the work itself has changed.
If a standard implementation has become a replacement problem, better implementation reporting does not remove the replacement risk. If migration is now the system constraint, increasing feature velocity does not increase transformation throughput. If unresolved architecture is creating rework, asking delivery teams for more precise commitments does not create architectural certainty.
The organization may believe it is increasing control while it is actually increasing the amount of governance surrounding an outdated model. This helps explain why large transformation programs can become more bureaucratic as they mature. More structure is added because predictability is decreasing, but the underlying reason for the decreasing predictability is not always examined. The transformation is still being governed according to what it was expected to be rather than what it has become.
Standardize the interfaces, not the transformation
If different transformation archetypes behave differently, and if they can change while the work is moving, then one fixed management model cannot adequately describe every part of a multi-year transformation. That does not mean governance should become inconsistent. It means consistency needs to be applied at a different level.
A migration should not require exactly the same evidence as exploratory enabling work. A decommissioning stream should not be measured in the same way as customer feature development. A standard platform implementation should not automatically inherit all the assumptions of a custom software initiative.
What can remain consistent are the structural questions around the work.
What are we changing? What kind of transformation is this now? Which assumptions does that classification depend on? What must be true before the work can move? Which decisions remain unresolved? Which systems, capabilities, or organizational units does it depend on? What evidence demonstrates readiness? What has changed since the work was originally shaped?
The answers will be different because the work is different. The discipline of making those answers visible can remain the same. This distinction is important because organizations often try to industrialize transformation by standardizing the transformation itself.
Experience produces more templates, more mandatory artifacts, more gates, and more prescribed processes. Eventually, the organization becomes very good at demonstrating that a project has followed the method without necessarily becoming better at determining whether the work is genuinely ready to move.
A better approach is to standardize the interfaces around changing work rather than the answers inside it.
This is the foundation of the Transformation Factory.
The Transformation Factory is a capability, not a department
The word factory can easily create the wrong impression. Transformation is not manufacturing. Architecture, organizational decisions, uncertain requirements, learning, and changing business conditions cannot be turned into a predictable production line simply by introducing more process.
The useful part of the factory idea lies somewhere else. A capable factory understands what has entered the system, what kind of processing it needs, where constraints are likely to appear, what quality means at different stages, and what must be true before something can move to the next state.
A Transformation Factory applies that structural discipline to enterprise change. It is the organizational capability to repeatedly take ambiguous transformation demand and make it sufficiently shaped, visible, and governable to move. It recognizes different transformation archetypes, identifies when the work changes shape, makes dependencies and decisions visible, establishes clear transition conditions, and applies governance appropriate to the type of work being processed.
The factory therefore does not produce identical transformations. It creates a repeatable ability to understand different transformations. This becomes particularly important at the interfaces between archetypes. Replacement may wait for enabling infrastructure. Migration may wait for data remediation. Implementation may wait for business standardization. Decommissioning may wait for adoption. Every team can appear productive while the transformation as a whole remains stationary.
Kersten's work on flow across product value streams points to the same underlying distinction: local activity is not the same as end-to-end movement of value. [3] When several transformation types coexist, the real constraint often sits between them rather than inside one team.
That brings us back to one of the central ideas in Transformation Patterns: activity is not flow.
A Transformation Factory must therefore make the interfaces between different forms of work observable, not merely make every individual team productive.
Transformation experience should accumulate
Most large organizations have transformed many times before. They have replaced applications, introduced enterprise platforms, migrated data, reorganized operating models, integrated acquisitions, and retired legacy technology. Yet a surprising amount of transformation capability disappears when each program ends.
The next transformation creates new governance, new templates, new terminology, and another temporary organization. Migration questions are rediscovered. Architecture uncertainties arrive late again. Business decisions once more become constraints at organizational boundaries. Decommissioning again turns out to be more complicated than expected.
The specific technical answers should not be copied from one transformation to the next. The patterns, however, should accumulate. Legacy replacement repeatedly creates coexistence problems. Standard implementation repeatedly exposes the distinction between real requirements and inherited customization. Data transformation repeatedly reveals questions of ownership and semantics. Decommissioning repeatedly proves to be organizational as much as technical. Cross-functional transformation repeatedly encounters decision latency at the boundaries between business, technology, architecture, and governance.
A Transformation Factory retains this knowledge. It does not preserve the previous solution and force it onto the next transformation. It preserves the ability to recognize the relevant questions earlier.
Conway's work reminds us that architecture and organization cannot be treated as independent either. The systems organizations create tend to reflect the communication structures through which they are designed. [4] As multi-year transformations reshape applications, platforms, teams, ownership, and decision rights, the organization performing the transformation changes alongside the technology.
This means coherence cannot simply be designed once at the start. It has to be restored repeatedly as the transformation evolves.
That is the deeper meaning of industrializing transformation. It does not mean making transformation repetitive. It means making transformation capability cumulative.
The transformation you finish will not be the one you started
Large transformations change shape because the system becomes better understood while it is being changed. Dependencies become visible. Assumptions fail. Architecture reveals itself. Migration proves harder than expected. Business decisions become unavoidable. Temporary solutions create new constraints. New capabilities create options that were not available at the beginning.
The leadership challenge is therefore not to prevent transformation from changing shape. Doing so would mean protecting the original plan from the information produced by the transformation itself.
The more useful question is whether the organization can recognize the change early enough to adapt deliberately.
Instead of asking only:
“Are we still following the plan?”
leaders also need to ask:
“What kind of transformation are we dealing with now, and does the structure around it still fit?”
The Transformation Factory is the organizational capability behind that question. It does not eliminate uncertainty, make every initiative identical, or replace judgment with process. It makes changing work more observable, interfaces more governable, and accumulated experience reusable.
A mature organization does not stop encountering difficult transformations. It stops encountering every transformation as though it were the first.
References
Donella H. Meadows — Thinking in Systems: A Primer
Why it matters: Meadows explains how behaviour emerges from system structure, feedback, relationships, and delays. This helps explain why transformation work reveals new dependencies and changes as the system becomes better understood.
John D. Sterman — Business Dynamics: Systems Thinking and Modeling for a Complex World
Why it matters: Sterman's treatment of dynamic complexity explains why the effects of transformation decisions can emerge indirectly or later than expected, making fixed assumptions increasingly unreliable over time.
Mik Kersten — Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework
Why it matters: Kersten's focus on end-to-end flow supports the distinction between productive local activity and actual movement across a transformation system.
Melvin E. Conway — How Do Committees Invent?
Why it matters: Conway's work connects organizational communication structures with the systems they produce, an important relationship when both architecture and organization are changing during a transformation.
Tags:
Comments