Digital transformation, done in the right order

What is a digital transformation strategy?

A digital transformation strategy is the plan that defines what the business will change, in what order, who owns each outcome, and how success gets measured. It is not a technology roadmap. Digital transformation itself is the integration of digital technology across operations, products and culture so that the way value is created and delivered changes; adopting tools without changing the operating model is procurement, not transformation.

The distinction decides who is accountable. A digital strategy names platforms and dates, and IT owns it. A digital transformation strategy names business outcomes, sequences the changes that produce them, and puts one named operator from the business on the hook for each. Most programs that stall have written the first document and called it the second.

Why do digital transformation projects fail?

They fail on governance and then blame the technology. McKinsey’s transformation research puts full success at roughly 30 percent¹, which is where the widely quoted digital transformation failure rate comes from. PwC’s 2026 survey of 767 operations executives found 89 percent saying their technology investments have not fully delivered the results expected². The two numbers describe one problem from opposite ends: the money moves, the operating model does not.

The clearest evidence that this is a decision problem rather than a capability problem sits in company size. Organizations under 100 people are 2.7 times more likely to report a successful transformation than organizations above 50,000¹. Smaller firms do not have better engineers or larger budgets. They have less distance between the person who decides and the person who ships. Every approval layer inserted between those two is a tax on learning speed, and learning speed is what transformation runs on.

Failure is usually a governance failure wearing a technology costume. The deciding variable is not the platform. It is whether one named person owns the business case end to end.

In practice that means the business case, the budget and the delivery backlog answer to the same owner. When the case sits with a sponsor, the budget with finance and the backlog with a vendor, nobody can trade scope against outcome. Scope wins, and the outcome quietly goes missing.

Digitization, digitalization and digital transformation: what is the difference?

The three words get used interchangeably in vendor decks, and they describe three different levels of change. Keeping them separate is not pedantry. Each level has a different owner, a different cost profile and a different test of done.

Most stalled programs are digitalization projects carrying a transformation budget. That is survivable when everyone knows it. It gets expensive when the board was sold the third row and is being delivered the first.

Where does the transformation money actually go?

Worldwide IT spending is forecast to reach 6.155 trillion USD in 2026, up 10.8 percent year over year, with software the fastest moving slice at a forecast 1.434 trillion USD, up 13.3 percent³. IDC puts spending specifically on digital transformation at almost 4 trillion USD by 2027, a 16.2 percent compound annual growth rate from 2022⁴.

Read the shape rather than the totals. Services and software together dwarf devices and data center systems, and that is where the risk lives. Hardware either works or it does not, and you find out in weeks. Services and software fail slowly, in requirements that drifted and integrations nobody owned, and you find out in quarters. Budget lines that fail slowly need governance, not more diligence at purchase.

What role do digital transformation apps play?

Digital transformation apps are the delivery vehicle of the transformation, not a downstream artifact of it. A strategy deck cannot change how a claim gets adjudicated or how a field crew is dispatched. The application people open every day does exactly that. The app is where the new operating model becomes real, which makes the software delivery pipeline the binding constraint on the whole program.

That reframes the build question. It is not “which platform” but “how quickly can we change what we shipped once we learn it was wrong”. Nobody gets the first version right. Programs that recover are the ones able to ship a corrected version this week instead of next quarter, and that capability is engineering practice rather than procurement: trunk based delivery, automated tests, one step deploys, real observability. It is worth treating delivery engineering as strategy rather than as the implementation phase at the back of the deck.

Who governs what ships?

App building has moved outside central IT. Low code platforms and citizen developers mean a department can put a working tool in front of users without a project number. The risk has relocated accordingly. The old question was whether the organization could build. The new question is who governs what ships: which data the tool touches, who reviews it, and what happens when the person who built it changes jobs. Programs that ignore this accumulate a shadow estate that is hard to secure and harder to retire. The fix is not a ban. It is a lightweight path that lets a citizen built tool earn supported status, the same way SaaS based business automation graduates from experiment to system of record.

How do you measure a digital transformation strategy?

Measure whether the organization can ship and recover. DORA’s research separates software delivery into performance tiers, and the gap is not marginal: elite performers deploy multiple times per day, hold change failure rate between 0 and 15 percent, and restore service in under an hour, while low performers deploy on a monthly to biannual cadence, fail on 46 to 60 percent of changes, and take one week to one month to recover⁵.

The chart shows the upper bound of each tier’s failure band. These are better transformation metrics than a roadmap status light, for one reason: they cannot be presented well. Percentage complete is a claim. Change failure rate is a measurement. If a program is two years in and change failure rate has not moved, the transformation has not happened yet, whatever the milestone chart says.

Pair the delivery metrics with two or three business measures owned by the same person: cycle time on the process being transformed, cost to serve, and one revenue or retention measure the change is meant to move. Four numbers on one page beats a forty page steering pack, and it forces the trade off conversation that steering packs are designed to avoid.

How is AI resetting the payback clock?

AI has changed the investment pattern faster than it has changed the return pattern. Deloitte’s 2025 survey of 1,854 executives across 14 countries found 85 percent had increased AI investment over the past twelve months and 65 percent now treat AI as part of corporate strategy, while only 6 percent reported AI investment paying back in under a year⁶.

The gap between spend and payback is where budgets die. A board told to expect returns in four quarters and shown them in eight cancels in month ten, usually just before the operating model change lands. The defensible move is to set the payback horizon in writing at the start, and to report delivery metrics in the interim so the program has evidence to show while the financial case is still maturing.

It also helps to calibrate against real adoption rather than announcement volume. The US Census Bureau’s Annual Business Survey, published in 2025, found 3.8 percent of US businesses using AI to produce goods or services⁷, and Eurostat reported 20 percent of EU businesses using AI in 2025, up from 13 percent in 2024⁸. The base is low and moving. So the competitive question is rarely “are we behind” and almost always “can we sequence this before the people we compete with can”. That is a question about where AI fits the operating model, not about model selection.

What is the right order, and how long does it take?

Sequence beats software. The order below is the one that survives contact with real organizations.

1. Name the owner before naming the technology. One person owns the business case, the budget and the backlog. If that person cannot be named, the program is not ready to start.
2. Pick one process and one measure. Not a portfolio. One process whose current cost or cycle time is already known, so the improvement is arguable in numbers rather than adjectives.
3. Fix the delivery pipeline first. If the team cannot ship weekly and recover in hours, every later decision gets made blind. This is the cheapest step and the one most often skipped.
4. Ship a thin slice into production. Real users, real data, narrow scope. The point is to learn what the requirements got wrong, which only production reveals.
5. Change the operating model, then scale. Roles, incentives and handoffs change, or the new app just becomes a faster way to run the old process.
6. Retire something. A transformation that only adds systems has not transformed anything. It has increased the run cost.

On duration, treat the first measurable outcome as a 90 day question and the operating model change as a multi year one, and never let the second excuse missing the first. Cost follows the same logic. The expensive part is rarely the license. It is the integration and the change of work, which is why scoping one process end to end produces a far more reliable number than scoping a platform.

An organization that gets the order right ends up holding an unglamorous asset: the ability to change its own processes quickly and safely. That is what transformation actually buys, and it compounds. The technology sitting on top will be replaced twice before the capability is.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.