Digital Transformation Without the Buzzwords: A Practical Guide

"Digital transformation" has been stretched to cover almost anything: a new CRM, a cloud migration, a mobile app, a reorganization. When a phrase means everything, it stops helping anyone make decisions.

A plainer definition is more useful. Digital transformation is changing how your organization serves its customers, staff and partners by redesigning services and the work behind them, using technology where it helps. The emphasis is on the service and the work. Technology is the means, not the goal.

This guide sets out a practical way to lead that kind of change. It draws heavily on public-sector design and delivery guidance, which is unusually candid and freely available, and on DORA's research-based measures of software delivery.

Start from a real problem and real users

The first of the UK government's design principles is "Start with user needs," and the guidance explains: "If you don't know what the user needs are, you won't build the right thing." That applies just as well to an internal expense process as to a public service.

Before committing to a program, run a short discovery. The UK Service Manual describes the purpose of discovery as understanding the problem before you commit to building anything, and it is explicit that "You should not start building your service in discovery." Discovery looks at:

• What users are trying to achieve and how they do it today, across the whole journey.
• Constraints such as legislation, contracts, legacy technology and existing processes.
• Opportunities to improve things, including alternatives to building a new system.

The manual also says it is "not a failure to stop at the end of the discovery phase" if research shows that is the best course. Building in that permission is one of the most effective ways to avoid expensive programs that never should have started.

Redesign the service, not just the screens

Many transformations simply digitize an existing paper process, complete with its unnecessary approvals and handoffs. The UK Service Standard asks teams to "Solve a whole problem for users" and to "Provide a joined up experience across all channels."

For example, imagine a hypothetical county permitting office that puts its paper form online. Applicants still wait weeks because the form is printed and routed between three departments. The real transformation is redesigning the routing and decision steps, possibly removing some entirely, so that the online form is the front of a faster service rather than a new entrance to the same queue.

Ask of every step: who needs this, what decision does it support, and what happens if we remove it?

Use small, multidisciplinary teams that stay together

The Service Standard calls for teams to "Have a multidisciplinary team," "Use agile ways of working" and "Iterate and improve frequently." In practice, that means a stable team with a product or service owner, designers, developers, and people who understand the policy and operations, working on one service over time.

The government design principles put it bluntly: "start small and iterate wildly," releasing minimum viable products early, testing with real users and moving from alpha to beta to live while deleting what does not work.

For an IT leader, the implications are organizational:

• Fund durable teams around services or products where you can, not only one-time projects that disband at go-live.
• Give each team a clear owner with authority to make trade-offs.
• Keep business and operations staff inside the team, not just in steering meetings.

Deal with legacy constraints honestly

Most transformation runs into existing systems, contracts and data. Treat these as part of the design problem from the start, not as surprises at integration time. The UK discovery guidance lists legacy technology among the constraints to find early.

Older systems also absorb budget. The U.S. Government Accountability Office reported in July 2025 that federal agencies "have typically reported spending about 80 percent on operations and maintenance of existing IT." Your organization's ratio will differ, but if most of the technology budget is consumed by running what already exists, transformation plans need to include retiring or modernizing systems, not just adding new ones. See our guide to technical debt and modernization for how to build that case.

Measure outcomes and delivery, without gaming

The Service Standard asks teams to "Define what success looks like and publish performance data." Define success in terms the user and the business care about: time to complete a task, error rates, cost per transaction, satisfaction or the share of people who finish online.

For the technology delivery itself, DORA's software delivery performance metrics are a widely used, research-based set. DORA currently describes five metrics, grouped into throughput (change lead time, deployment frequency and failed deployment recovery time) and instability (change fail rate and deployment rework rate). DORA cautions that the metrics are meant to be applied at the application or service level and that comparing very different applications can be misleading.

Report both kinds of measures together. Fast delivery of a service nobody uses is not success, and neither is a well-liked service that takes a year to change.

A simple leadership checklist

• Can you state the problem in one sentence without technology words?
• Has a team spent time with real users and front-line staff before committing?
• Is stopping after discovery a genuinely acceptable outcome?
• Is there one accountable owner per service, with a stable team?
• Does the plan include retiring old systems and processes, not just adding new ones?
• Are success measures defined before launch, and will you share them?

Key takeaways

• Define transformation as redesigning services and the work behind them, with technology as the means.
• Start with user needs and a short discovery, and treat stopping as an acceptable result.
• Solve whole problems end to end instead of digitizing broken processes.
• Use stable, multidisciplinary teams that release early and iterate.
• Plan for legacy constraints and measure both user outcomes and delivery performance, without misleading comparisons.

Sources

• Government Digital Service and Central Digital and Data Office, Government design principles
• Government Digital Service, Service Standard (Service Manual)
• Government Digital Service, How the discovery phase works (Service Manual)
• DORA, DORA's software delivery performance metrics (updated January 5, 2026)
• U.S. Government Accountability Office, Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems, GAO-25-107795 (July 17, 2025)