Transformation Is Not a Project: How Publishers Build Change That Lasts
Speaker
Executive summary
Technology is often the most visible part of transformation, but it is rarely the hardest part. The difficult work sits in implementation: decisions, ownership, data, communication, support, behavior, and the workarounds people create when the formal process does not help them get the job done.
Amy Jones reframes transformation as an organizational capability rather than a sequence of projects. A successful initiative should leave behind cleaner architecture, clearer routes for decisions, more confident teams, and reusable patterns that lower the cost and risk of the next change. Her closing question provides a practical test for every business case and retrospective: What will be easier next time?
Key takeaways
- Transformation should be judged by human and operational outcomes, not by whether a new system went live.
- A strong foundation is anything the next team can stand on, including architecture patterns, service layers, data models, governance routes, and support models.
- Small improvements can return capacity to overloaded teams and create momentum for the next improvement.
- Governance should offer different routes for different levels of risk, rather than forcing every change through the same heavy process.
- Capability building goes beyond tool training. People need context, participation, confidence, guardrails, and ownership.
- A project has created lasting transformation only when the organization can continue improving after the project team has gone.
What publishers can do next
- Add the question "What will be easier next time?" to transformation business cases, steering meetings, and retrospectives.
- Inventory recurring spreadsheets, manual workarounds, and unexplained process steps. Treat them as evidence of where the formal operating model is failing.
- Classify change requests into self-serve, supported, and fully managed routes with clear criteria for each.
- Select one high-friction workflow and deliver several small fixes before committing to a comprehensive redesign.
- Assign long-term operational ownership before the project team or implementation partner leaves.
- Build practical AI and data capability across functions instead of relying on one-off demonstrations or tool training.
Examples and evidence
- Emerald created a reusable service layer between a transformed front end and legacy back-end systems, reducing the risk of future platform changes and point-to-point integrations.
- A review of one customer-service process area identified 65 possible improvements. Emerald implemented 21 in less than a couple of months, with most fixes taking days rather than weeks.
- Emerald's first AI and Data Academy cohort includes 10% of the organization and spreads participants across business functions.
Important nuance
Amy did not argue that publishers should avoid large programs. Her point was that major programs still need reusable foundations, visible improvements, practical governance, and capability building. Without those elements, a publisher may deliver a project without becoming better at transformation.