Do 70% of Digital Transformations Really Fail?

No reliable study shows 70% of digital transformations fail. The figure traces to Hammer and Champy's 1993 estimate, which they called unscientific. BCG's 2020 study found 70% of digital transformations fell short of their objectives; McKinsey's 2018 survey found 16% of respondents reported improved and sustained performance. In Unolabs' experience, the recurring causes are scope, people and data, not technology.

Go to any conference on digital transformation and you will see the same slide. A big red number: seventy percent fail. Usually with a McKinsey or BCG logo sitting next to it, although neither firm's research measured outright failure.

It makes a great opening line. It is also a little more complicated than that, and the complications matter, because that number shapes how boards fund transformation, how much patience they have, and how quickly they give up on a programme that is struggling.

#Where Does the 70 Percent Figure Come From?

What this means for you: the number on the conference slide is older than digital transformation, and nobody has measured it cleanly.

The figure predates the word "digital". In their 1993 book Reengineering the Corporation, Michael Hammer and James Champy estimated that 50 to 70 percent of reengineering efforts did not achieve the results intended, and they described that estimate as unscientific. Seven years later, Michael Beer and Nitin Nohria wrote in Harvard Business Review (2000) that about 70 percent of all change initiatives fail.

From there the number travelled. It moved from reengineering to change management, and from change management to digital transformation, picking up a consultancy logo along the way.

In 2011, Mark Hughes of the University of Brighton went looking for the evidence. Writing in the Journal of Change Management, he reviewed five of the most cited published sources for the claim, including Hammer and Champy, Beer and Nohria, and John Kotter. He found no valid and reliable empirical evidence to support a 70 percent failure rate for organisational change.

None of this means transformation usually succeeds. It means the number on the slide is the wrong evidence. Better evidence exists, and it is more useful, because it says something about why programmes miss.

#What the Digital Transformation Studies Actually Measured

What this means for you: the credible studies measure falling short of objectives, as judged by the executives involved, which is a different and more actionable finding than "failure".

The closest real source for the digital version of the claim is a BCG study published in October 2020. It drew on BCG's own experience with 70 leading companies and responses from 825 senior executives, and found that 70 percent of digital transformations fell short of their objectives.

Fell short, not failed. Those are different things.

A programme that delivered a working platform but missed its revenue target fell short. So did one that landed a year late. Neither is the same as a programme that was written off, and the difference matters when a board is deciding whether to fund the next phase.

McKinsey's survey, published in October 2018 and drawing on more than 1,700 respondents, tells a similar story from a harsher angle. Only 16 percent said their organisation's digital transformation had improved performance and also equipped it to sustain those changes in the long term. The same 2018 McKinsey report notes that its wider research on transformations of every kind puts the success rate at less than 30 percent.

Both modern studies rely on executives grading their own programmes, so nobody has measured failure cleanly. But you don't need a perfect number to see the pattern. On BCG's figure, about 30 percent of programmes deliver what was promised; on McKinsey's stricter test of improved and sustained performance, fewer than one in five respondents report it.

#Why So Many Programmes Fall Short

What this means for you: the causes that keep recurring sit in how programmes are shaped and run, not in the technology chosen.

Three reasons keep coming up in our conversations with enterprise teams. They line up closely with BCG's 2020 findings. The companies that got six factors right, among them an integrated strategy with clear goals, leadership commitment from the CEO through middle management, and a business-led, modular technology and data platform, flipped their odds of success from 30% to 80%.

#Scope: a bet, not a plan

By the time results arrive on a long programme, the business has moved on, the sponsor has changed, and the original problem looks different. The plan was written for a company that no longer quite exists.

Long programmes also delay the moment anyone can check whether the plan was right. Every month without a working system is a month of assumptions stacking up, each one untested and each one making the next harder to unwind.

#People: change designed in, not rolled out

Teams are handed new systems without being told why their work is changing, and they quietly route around them. The spreadsheet that was meant to be retired is still running in parallel a year later, because nobody asked the people who used it what it did for them.

Effective change management has to be designed in during the first phase, not rolled out at go-live. In practice that means the people whose work changes are in the room when the process is redesigned, adoption is measured alongside delivery, and the old way of working is retired on a date rather than left running indefinitely.

#Data: the foundation underneath

If the data feeding a new platform is inconsistent or ungoverned, no amount of tooling hides it for long. Departments define the same measure differently, master data is duplicated across systems, and the first reports out of the new platform are met with the same distrust as the old ones.

This is why data governance belongs in the first wave rather than the last, and why a semantic layer that defines each measure once often matters more to adoption than the platform it sits on. The same pattern runs through ERP modernisation, where treating S/4HANA as a data architecture decision rather than a migration decides most of the outcome.

#What a Transformation That Works Looks Like

What this means for you: smaller pieces, earlier proof and ownership at the end change the odds more than a better three-year plan does.

Smaller, for a start. Pieces of three to six months, each one delivering something real, each one paying for the next. At Unolabs the target is a first production wave in 16 to 24 weeks: a working system the business uses, not a roadmap that needs three years of faith.

Change management starts on day one, alongside the architecture. The data foundation gets fixed before anything intelligent is built on top of it, which is the same order a well-built data and AI roadmap follows. And the programme ends with the client owning the system outright, able to run it without calling the vendor every time something changes.

That last point is easy to agree with and hard to deliver, so it is worth testing before you choose a delivery partner: ask who holds the code, the documentation and the run books on the day the engagement ends.

1. Pieces of three to six months, each with a working result the business uses.
2. Change management from the first phase, with adoption measured alongside delivery.
3. The data foundation fixed first, so nothing intelligent is built on data nobody trusts.
4. Ownership at the end, with the client able to run and change the system itself.

None of this is exotic. It is just less comfortable than a three-year plan with a big launch date, which is why, in our experience, few programmes are built this way.

#How to Tell Whether Your Programme Is on Track

What this means for you: status reports measure activity; the most reliable signal is something live, used and moving a number the business cares about.

Most programme reporting measures activity: milestones hit, environments built, users trained. None of it tells you whether the business is better off. A programme can be green on every one of those measures and still fall short of its objective, which is roughly what the BCG and McKinsey figures describe.

The alternative is to track outcomes from the first piece onwards, on a small set of agreed measures that the steering committee reviews. The same discipline that makes executive dashboards worth opening, a handful of governed measures tied to decisions, applies to the programme itself.

#When a Long Programme Is the Right Shape

What this means for you: some transformations genuinely cannot be cut into six-month pieces, and pretending otherwise causes its own damage.

Some work is long by nature. Replacing a core ERP against a vendor deadline, consolidating regulated platforms where parallel running is mandatory, or integrating two businesses after a merger can each take years, and a plan that promises otherwise is not credible.

The 31 December 2027 end of mainstream maintenance for SAP ECC is a current example: an S/4HANA transformation has a fixed end date and a large scope, and no amount of slicing removes either.

Even then, the principle holds inside the programme. Release in increments where the platform allows it, prove value early through work such as data cleansing and reporting continuity, and make the long horizon a series of funded checkpoints rather than one launch date. A long programme is a decision; an unexamined one is a risk.

#The Better Question to Ask

What this means for you: replace a question nobody can answer with one any programme team should be able to answer today.

"Will ours fail?" is hard to answer and easy to dodge. A sharper one is this: what will be live, and working, six months from now? We call this the six-month test: four questions a board can put to any plan.

1. What will be live and working in six months, and who will use it?
2. Which measure should move, and who owns that measure?
3. What data does it depend on, and is that data governed today?
4. Could your own team run it without calling the vendor?

If the plan cannot answer those clearly, the board is not funding a change programme.

You are not looking at a transformation. You are looking at a long wait with a good slide deck.

At Unolabs, the six-month test is how we scope our engagements, from digital transformation and data strategy to AI readiness, and it is the same reason we argue that AI governance is an engineering problem: what matters is what runs, not what is promised.

#Frequently Asked Questions

#Do 70% of digital transformations really fail?

Not on the evidence available. BCG's 2020 study found that 70% of digital transformations fell short of their objectives, which is not the same as failing outright. McKinsey's 2018 survey found that 16% of respondents reported improved and sustained performance. Both rely on executives grading their own programmes, so the honest summary is that most fall short and roughly 30% at best deliver what was promised.

#Where does the 70% failure statistic come from?

It predates digital transformation. Hammer and Champy estimated in 1993 that 50 to 70 percent of reengineering efforts missed their intended results, calling the estimate unscientific. Beer and Nohria wrote in Harvard Business Review in 2000 that about 70 percent of change initiatives fail. Mark Hughes reviewed the main sources in 2011 and found no valid empirical evidence for the figure.

#Why do digital transformations fall short?

In Unolabs' experience, three causes recur. Scope that takes 12 to 24 months to show results turns the programme into a bet. Change management treated as an afterthought leaves teams routing around new systems. Inconsistent, ungoverned data undermines every report and model built on the new platform. BCG's 2020 study found that companies getting six factors right raised their odds of success from 30% to 80%.

#How long should a digital transformation take to show results?

Something real should be live within months, not years. Cutting the work into pieces of three to six months, each delivering a working result, lets the business test the plan early and fund the next piece on evidence. Unolabs targets a first production wave in 16 to 24 weeks. Some programmes, such as ERP replacements, are long by nature, but they can still release value in stages.

#How do you measure digital transformation success?

Measure outcomes rather than activity. Milestones met and users trained do not show whether the business is better off. Agree a small set of measures before the programme starts, tie each to a decision or a business result, and review them from the first release onwards. The simplest test is whether something is live, used and moving a number the business cares about within six months.

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing whether your transformation plan will show results in time, book a discovery call and we will work through it with you.