A recent discussion raised a deceptively simple question: why are transformation readiness and adoption so often reported by the same program team responsible for delivering the transformation?
This is common across large ERP, CRM, PDM/PLM, MES, and other enterprise transformation programs. The program establishes the milestones, defines the readiness and adoption measures, collects the evidence, and consolidates the status. The same governance structure then reports whether the organization is ready before deployment and whether the transformation has been successfully adopted afterward.
There is nothing inherently wrong with programs measuring these things; in fact, it is essential and often neglected by implementation partners. The problem arises when program reporting becomes the primary evidence that the organization is ready and that adoption has occurred. Delivery management and assurance then become difficult to distinguish.
Would we design financial, quality, cybersecurity, or regulatory controls this way? Probably not. So why do we accept it for transformations that can fundamentally change how an organization operates?
Readiness is not adoption
The distinction matters. Readiness asks whether the organization can operate effectively in the new environment. Adoption asks whether it actually does.
Transformation programs naturally operate around milestones: design completed, data migrated, testing passed, solution validated, users trained, and cutover approved. These are necessary controls, but completing them does not necessarily establish readiness.
The same problem continues after MVP deployment. Users have logged in, transactions are being processed, support tickets are declining, and legacy applications may have been switched off. Again, these are useful indicators, but they do not necessarily demonstrate adoption.
Training completion does not prove user competence. Successful migration does not prove that the data is sufficiently accurate and usable. Login statistics do not prove that the intended business process is being followed. Transaction volumes do not demonstrate that workarounds and parallel processes have disappeared.
We frequently measure what the program can easily observe and use it as a proxy for outcomes that are considerably harder to observe.
Why does everything become green?
Anyone who has worked on major transformation programs will recognize the pattern. As deployment approaches, readiness dashboards progressively move from red to amber and from amber to green. After go-live, adoption dashboards often follow a similar trajectory.
This does not require deliberate manipulation. Programs operate under pressure to deliver. Resources have been mobilized, business teams have prepared for cutover, partners have committed capacity, and leadership expectations have been established. Moving a deployment can have significant consequences.
Issues are therefore mitigated, actions assigned, workarounds accepted, and residual risks documented. A training gap becomes manageable because additional support will be available during hypercare. A data-quality issue is accepted because remediation can continue after deployment.
The same can happen with adoption. Low usage becomes a training issue. Continued spreadsheet use becomes temporary transition behavior. Process deviations become local exceptions. Benefits that have not materialized move into a longer-term benefits-realization horizon.
Each judgment may be reasonable. Collectively, however, they can create a substantial gap between program-reported success and operational reality.
The technology can be live without the transformation being adopted
ERP, CRM, PDM/PLM, and MES illustrate this particularly well because they sit within complex, interconnected business systems rather than operating independently. Transformation complexity does not come simply from the technology; it comes from the dependencies among people, processes, data, organizations, and multiple technology platforms. A program can therefore be green within its own boundaries while important dependencies remain unresolved elsewhere in the enterprise.
An ERP platform can be technically stable while procurement or finance teams manually compensate for process weaknesses. CRM can show excellent login statistics while sales teams maintain critical customer information elsewhere. PLM can successfully manage product structures and workflows while engineering teams continue exchanging information through spreadsheets and email. MES can process production transactions while operators maintain parallel processes because they do not yet trust or use the new environment efficiently.
In every case, the technology is live, and people may be using it. Yet the intended transformation may not have been adopted.
The relevant question is therefore not simply whether the system works, but whether the operating model works with it and has become the organization’s normal way of operating.
That requires evidence from real end-to-end processes. Can people execute their roles without program support? Have legacy processes genuinely disappeared? And, perhaps most revealingly, what work is still happening in Excel, email, shared drives, or other tools outside the intended process?
Continued use of Excel does not necessarily mean poor adoption. But when users rebuild processes, data, or decisions outside the new platform, it raises a sharper question:
Is this an adoption problem, or evidence that the transformation did not fully address how the business actually works?
These questions are harder to represent on a dashboard, but they are much closer to what transformation is supposed to achieve. The greater the transformation complexity and the number of interdependencies, the less credible a single aggregated readiness or adoption measure becomes.
Who owns the assessment?
The program should own its delivery plan and provide evidence against its commitments. Business leaders and process owners should own operational readiness and adoption. Technology, architecture, data, security, risk, and other functions should provide assurance within their respective domains.
The assumption that the program can also be the sole judge of the outcome it was established to deliver should be challenged.
This does not require another bureaucratic assurance layer. It requires credible challenge, clear accountability, and evidence that can withstand scrutiny outside the delivery organization.
Instead of asking whether training is green, ask whether people can perform the critical activities required by their roles. Instead of asking whether adoption has reached 90%, ask what that 90% actually represents. Instead of celebrating transaction volumes, determine whether the intended processes are being followed and whether parallel processes have disappeared.
Most importantly, ask:
What evidence would cause us to conclude that we are not ready or that adoption has not occurred?
If the governance process makes either conclusion practically impossible, then we are probably measuring progress toward an expected answer rather than objectively assessing transformation.
Go-live is not the finish line
Go-live is important, but it is ultimately the point at which many transformation hypotheses begin to be tested in the real organization.
Before go-live, we are primarily assessing readiness. After go-live, we can observe adoption. Only then can we properly assess outcomes and value realization.
These should not be collapsed into a single program status. An organization can be ready but experience weak adoption. It can achieve high system usage without delivering the expected business outcomes. Equally, adoption can take longer than planned while ultimately producing substantial value.
The underlying issue therefore extends beyond change management and beyond ERP, CRM, PDM/PLM, or MES. It is a question of transformation governance.
Readiness should demonstrate that the organization can operate. Adoption should demonstrate that it is operating in the intended way. Outcomes should demonstrate that the change is delivering the value that justified the transformation.
The program should provide evidence and make its recommendation, but it should not be the only judge of whether that evidence proves success.
What are your thoughts?
Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption.
About the Author
