Insights · Transformation · 8 min read
Transformation is 20% technology. Budgets usually say the opposite.
BCG studied 900 transformations. The technology hardly separated winners from losers — the people and process work did.
The most useful study of transformation success is also the least dramatic. BCG examined 900 digital transformations and found 30% met or exceeded their targets, 44% created some value but fell short, and 26% produced little or nothing. The famous "70% fail" line comes from adding the last two together — which flattens the most interesting part of the data, because the middle 44% did not fail. They bought the right things and then under-executed everything around them.
That middle band deserves more attention than the failures, because it is where most programs actually land, and because its cause is consistent: the technology decision was defensible, and everything around it was underfunded.
Same technology, different outcomes
The platforms available to the 30% and the 26% were the same platforms, sold by the same vendors, implemented against the same reference architectures. What separated the outcomes, across BCG's factors and McKinsey's parallel research, was almost entirely non-technical.
BCG identified six factors that together flipped the odds from roughly thirty percent success to eighty: an integrated strategy with clear outcomes; leadership commitment that runs from the CEO through middle management rather than stopping at the sponsor slide; high-caliber talent actually freed up to do the work; an agile governance mindset that adapts as facts change; effective monitoring against measurable outcomes; and a business-led, modular technology platform. Note the order — five of the six are about people, leadership and process. McKinsey's research is blunter still: culture and working practices decide more than the technology does, and organizations that invest seriously in the change side succeed at multiples of the rate of those that do not.
Yet look at how a typical program budget divides and the proportions run the other way. The platform is the headline number; the training, process redesign and adoption work are contingency lines, and they are the first lines cut when the schedule slips. The evidence says the determining factors get the leftovers.
The middle 44% is the cautionary tale: the technology decision was defensible, and everything around it was underfunded.
How the middle band happens
The pattern is recognizable across industries. A commerce replatform launches on time and then spends two quarters reconciling orders with a warehouse system nobody scoped, because the integration map was drawn from the architecture diagram rather than from how orders actually move. A new system arrives with training built for head office and none for the people who generate the revenue. A process that officially takes five steps turns out, in the field, to take eleven — and the software faithfully automates the five.
None of those are software problems. All of them sink software projects. They share a root: the program treated the organization as the recipient of the change rather than the substance of it. The processes were mapped as documented rather than as performed, the people who had to work differently found out at rollout, and success was measured at go-live — the one date on which no transformation has ever created any value. Value arrives in the months after, through adoption, and adoption is exactly the work the budget treated as contingency.
The questions that predict which band you land in
Before approving the next program, five questions are worth more than any vendor comparison. Who has to work differently for this to succeed, and do they know yet? What does the business case assume about adoption, and who owns making that assumption true? Which processes have been mapped as they actually run — workarounds and spreadsheets included — rather than as the process documentation claims? What gets measured in the two quarters after go-live, and who is still accountable then? And when the schedule slips — it will — what gets cut: the integration testing and the training, or the launch date?
The last answer, honestly given, is usually the whole forecast. Programs that protect the launch date at the expense of the adoption work are choosing the middle band in advance; they will go live on time and under-deliver for two years. The 30% make the opposite trade, because they understand what the study keeps confirming: the technology was never the bet. The organization was.