The word has outgrown its usefulness
Digital transformation has become broad enough to describe almost anything: a new CRM, a website rebuild, an automation programme, a move to the cloud, or an experiment with artificial intelligence. That flexibility makes the phrase easy to sell and difficult to manage. When every technology initiative becomes transformation, leaders lose the distinction between installing a tool and changing the way the organisation works.
A more useful definition starts with value. Transformation changes how a business understands demand, makes decisions, delivers a service, and learns from the result. Technology can enable that change, but it cannot supply the intent. The OECD’s work on human-centred digital transformation makes the same point at a societal scale: digital progress creates opportunities and risks, and its success depends on putting people first. For a business, that means beginning with the experience of customers and employees rather than the features of a platform.
Start with the operating problem
The strongest transformation briefs do not begin with “we need an app”. They begin with an observable constraint: customers cannot complete a task without calling support; teams reconcile the same information across three systems; a product takes weeks to change because nobody owns the whole journey. These statements connect a human problem to an operational cost. They create room to consider process, policy, content, data, and technology together.
This framing also prevents a common failure: digitising a broken process exactly as it exists. A paper form moved online may be faster to distribute while remaining confusing to complete. An automated approval chain may move bad decisions more efficiently. Before adding software, trace the service end to end. Identify repeated work, missing information, hand-offs, delays, and decisions that lack clear ownership. The first transformation opportunity is often subtraction.
Treat adoption as part of the product
A technically sound system can still fail if people do not understand it, trust it, or see how it helps them. Adoption is not a communications task saved for launch week. It should shape the service from discovery onward. Employees who run the current process hold practical knowledge that rarely appears in requirements documents. Customers reveal workarounds and anxieties that analytics alone cannot explain. Bringing both groups into research and testing improves the design and builds ownership of the change.
The implication is important: training cannot compensate for an incoherent product. If ordinary tasks require lengthy instructions, the team should first question the interaction, terminology, permissions, and workflow. Good enablement then focuses on the genuine change—new responsibilities, decisions, and ways of working—rather than teaching people how to navigate avoidable complexity.
Build capability, not dependency
Transformation programmes often create a temporary surge of external expertise and an enduring internal gap. The programme launches, the specialists leave, and the organisation struggles to improve what it now owns. A better model pairs delivery with capability transfer. Internal people join research, prioritisation, design reviews, technical decisions, and measurement. Documentation explains why the system works as it does, not only where the files live.
External partners are most valuable when they increase the organisation’s ability to make good decisions after the engagement. That can mean establishing a design system, improving product governance, creating a usable analytics model, or coaching an internal team through the first release. The goal is not self-sufficiency in every discipline. It is informed ownership: knowing what matters, what good looks like, and where specialist help produces leverage.
Measure the changed behaviour
Launch is an output, not evidence of transformation. The meaningful measures sit closer to the problem: fewer avoidable calls, shorter completion time, higher successful self-service, reduced rework, faster release cycles, better data quality, or increased customer confidence. Choose a small set before delivery and establish a baseline. Without that comparison, every post-launch story becomes anecdotal.
The most credible transformation programmes are often the least theatrical. They connect a defined problem to a changed service, release in useful increments, and measure whether behaviour improved. They are willing to stop work that does not earn its complexity. The question is not whether an organisation has adopted enough technology. It is whether people can now do something important more clearly, reliably, or effectively than before.
Manage transformation as a portfolio
No organisation transforms everywhere at once. Attempting to do so spreads attention across too many dependencies and makes it difficult to tell which investment created value. A portfolio view forces choices. Group opportunities around customer and operational outcomes, then compare their likely value, urgency, evidence, complexity, and organisational readiness. A smaller initiative that removes a daily point of friction may create more momentum than a high-profile platform with a distant payoff.
The portfolio also needs explicit connections. A new customer journey may depend on data quality work that looks unremarkable on its own. A self-service product may require policy changes and support-team preparation before adoption can improve. Showing these relationships helps leaders fund the conditions of success rather than only the visible interface. It also creates a sensible sequence: prove value in a bounded area, reuse what works, and expand with evidence. Transformation becomes a series of connected operating improvements, not one heroic programme expected to solve the organisation in a single release.