Optimize Growth and revenue with Digital Transformation
You have probably been told that 70% of digital transformations fail. We went looking for the study behind that number and could not find one. What exists is change-management research about corporate transformations in general, repeated until it became a statistic about digital projects. This post is about what the evidence actually supports, and what to measure instead.
Key takeaways
- No credible study establishes 70% as a measured digital transformation failure rate under a consistent definition.
- The figure traces to general change-management research, not to digital projects specifically.
- Published failure rates range from 70% to 95% depending on the source and on how “failure” is defined — which is the tell.
- A number that wide is not a measurement. Judge your own programme on whether a named person's work changed.
Does 70% of digital transformation really fail?
There is no study that shows it. The clearest version attributed to McKinsey is a 2019 interview in which the 70% refers to academic research on corporate transformations in general rather than digital ones (McKinsey). A review that tried to trace the number concluded it found no credible study that establishes 70 percent as a measured digital transformation failure rate under a consistent definition, and that the chain of citation runs back through change-management writing to Kotter rather than to any digital dataset (ReliaMag).
Meanwhile the quoted rate varies from 70% to 95% depending on who is selling. When a statistic has a 25-point range and no agreed definition of the thing being counted, it is rhetoric.
What the claim says against what the evidence supports
| The claim | What the evidence supports |
|---|---|
| “70% of digital transformations fail” | No study measures this under a consistent definition |
| “McKinsey found 70%” | A McKinsey interview cites 70% for corporate transformations in general |
| “The rate is 70–95%” | The range itself shows “failure” is undefined |
| “Therefore you need a transformation programme” | Does not follow from any of the above |
So what should you measure instead?
Whether a named person's work actually changed, and whether the thing you could not previously answer is now answerable. Both are checkable in weeks and neither needs a definition of transformation.
Concretely: pick one process that is high-volume, repetitive and checkable. Record how long it takes and how often it is wrong. Change it. Measure again. That is a smaller claim than transformation and it is the one you can defend to a board.
Where does this kind of spending actually pay back?
In our experience, on the narrow work rather than the broad programme: invoices, support tickets and management reports — tasks that are high-volume, repetitive and easy to check. We wrote that up with the tests for each in where AI pays off in an Indian SME. For budgets, the custom software development cost guide has the ranges.
The published evidence on large programmes is also worth knowing before committing to one: research across more than 5,400 IT projects found an average 45% cost overrun and 56% less value than predicted, and that every additional year of planned duration added around 15% to the overrun (McKinsey). That is an argument for short, finishable pieces of work rather than a multi-year programme.
What we have seen at DECK IT
We build custom software from Ahmedabad for companies in India and the United States. The pattern we see is not that transformations fail; it is that they were never specified tightly enough to succeed or fail.
A programme with no stated way to be wrong cannot be evaluated. Ask what result would mean the work was not worth doing. If nobody can answer, the scope is a direction rather than a project.
The cheapest wins are usually in the gaps between systems that already work: a handoff done by email, a comparison nobody runs. Those are weeks of work, not a transformation, and they pay back first.
Frequently asked questions
Do 70% of digital transformations fail?
There is no study that measures this. The figure traces to change-management research on corporate transformations in general, and quoted rates range from 70% to 95% depending on the source and the definition of failure.
Where did the 70% figure come from?
The chain of citation runs back through change-management writing, including Kotter, rather than to any dataset of digital projects. The clearest McKinsey-attributed version is a 2019 interview referring to transformations in general.
What should we measure instead?
Whether a named person's work changed, and whether a question you could not answer before is now answerable. Both are checkable within weeks and neither requires defining transformation.
Should we run a multi-year transformation programme?
Rarely. Research on large IT projects found that each additional year of planned duration added about 15% to the cost overrun, which argues for short, finishable pieces of work that each deliver something.
Where does this spending pay back soonest?
On work that is high-volume, repetitive and checkable, and in the gaps between systems that already work. Those are usually weeks of effort rather than a programme.
Conclusion
Be suspicious of a statistic with a 25-point range and no definition behind it, particularly when the person quoting it sells the cure. Pick one process, measure it, change it, measure again. That is less impressive than a transformation and considerably more likely to work.
If you would like a second opinion on which process to start with, tell us what you run.