< journal.entry />
The Real Reason Digital Transformation Projects Fail
It is rarely the software. Most digital transformations fail because stakeholders cannot define what they need, and “we will update later” becomes a ticking bomb.
Adi Sulaksono
Companies do not fail digital transformation because they picked the wrong cloud vendor. They fail because nobody could answer a simple question early enough: what must change in how we work, and what are we willing to decide now?
The real reason so many projects collapse is not technology immaturity. It is stakeholder incapability to know what they need, combined with a dangerous habit of saying "just ship it, we will update later." That phrase sounds agile. In practice, it plants a ticking bomb under the new system.
The Numbers Have Not Improved
Through 2025–2026, the headline statistics remain stubborn:
- Around 70% of digital transformation initiatives still fail to meet their objectives, a figure repeated across McKinsey, BCG, and industry analyses for years, with little meaningful improvement.
- Gartner’s CIO survey found only 48% of digital initiatives meet or exceed business outcome targets.
- Bain’s research has reported that 88% of business transformations miss their original ambitions.
- BCG’s analysis of 850+ companies has put true goal achievement closer to ~35% in some datasets.
- Failed transformation efforts are estimated to cost businesses about $2.3 trillion a year, while global digital transformation spend was projected near $3.4 trillion by 2026.
In May 2026, BCG restated the uncomfortable truth: corporate transformations fail far more often than they succeed, and the ~70% failure rate has barely moved for decades, even while technology itself advanced dramatically.
If the tools got better and the failure rate did not, the bottleneck is not the stack. It is how organizations decide, align, and defer.
The Comfortable Excuse vs. the Real Failure Mode
Leaders often blame:
- Legacy systems
- Vendor delays
- Budget cuts
- “Users resist change”
- Missing AI / cloud / integration features
Those can be real. They are usually secondary.
The primary failure mode I keep seeing looks like this:
- Executives approve a transformation slogan (“go digital,” “modernize ERP,” “become data-driven”)
- Stakeholders cannot describe outcomes in operational detail
- Delivery teams start building against vague workshops and conflicting opinions
- Hard decisions get postponed to “phase 2”
- The system goes live with workarounds embedded as permanent architecture
- Six to eighteen months later, the bomb detonates: rework, shadow IT, adoption collapse, and a second transformation to fix the first
That is not bad luck. That is a predictable outcome of unclear need plus deferred truth.
Stakeholders Who Do Not Know What They Need
This is not an insult. Most stakeholders are experts in their current job, not in designing a future operating model.
In workshops they say things like:
- “We need a dashboard”
- “Make it like the old system, but nicer”
- “It should be flexible”
- “AI should help somehow”
- “Just copy what competitor X does”
None of those are requirements. They are anxieties wearing product language.
When stakeholders cannot define what they need, three things happen:
1. Requirements become a negotiation theater
Every department fights for their exception. Nobody owns the end-to-end process. The project manager documents contradictions as “open questions,” then schedules another meeting.
2. Build teams invent the business
Engineers and consultants fill the vacuum with assumptions. Sometimes those assumptions are smart. Often they encode the loudest stakeholder’s preference, not the company’s strategy.
3. Success becomes “go-live,” not value
If nobody defined the outcome, shipping the platform becomes the only measurable win. Gartner’s finding that less than half of initiatives hit business outcome targets is exactly what you expect when outcome definition was weak from day one.
Unclear need is expensive
Every week without a decided process design is a week of code that may have to be thrown away, or worse, kept forever as a workaround.
“We Will Update Later”: The Ticking Bomb
The most dangerous sentence in digital transformation is not “this is impossible.”
It is: “For now, just hardcode it / customize it / skip the integration / keep the old workaround, we will update later.”
“Later” rarely arrives with budget, political capital, and clean architecture. Later arrives with production users, month-end closing pressure, and a vendor contract already signed.
Why deferred updates become bombs
| Deferred decision | What it looks like at go-live | How it explodes later |
|---|---|---|
| Unsettled approval workflow | Manual overrides and email approvals | Fraud risk, audit failure, process chaos |
| “Temporary” customizations to match old habits | Heavy ERP/CRM config debt | Upgrade path blocked; every release becomes a crisis |
| Missing master data ownership | Duplicate customers, SKUs, cost centers | Reporting lies; AI/analytics initiatives stall |
| Integration “phase 2” | CSV uploads and shadow spreadsheets | Two sources of truth; ops teams stop trusting the system |
| Security / access model postponed | Shared logins, broad admin roles | Breach, compliance findings, emergency lockdown |
| Training treated as optional | Super-users carry the whole company | Burnout, quiet reversion to Excel |
APQC-style research and recent project-management writing keep landing on the same mechanism: in digital initiatives, project decisions quickly become permanent operational constraints. Workflows, data definitions, and approval logic get embedded into systems people use every day. Changing them afterward is slow and expensive.
That is the bomb. Not a dramatic outage on day one, a slow fuse of irreversibility.
California Management Review’s 2025 work on technical debt makes the managerial point explicit: treating debt as “an IT cleanup later” ignores that business managers often cannot see it, while still demanding new digital options that add more maintenance burden. Debt becomes lethal when it constrains the organization’s ability to transform, precisely the moment leaders thought transformation had already happened.
What Failure Looks Like on the Ground
A typical pattern across ERP, CRM, POS, and internal platform projects:
Month 0–2: Kickoff energy. Vision slides. Vendor demos. Everyone agrees on “customer-centric” and “real-time.”
Month 3–6: Requirements workshops produce a 90-page document and still no single owner for order-to-cash exceptions. Developers start anyway because the timeline is fixed.
Month 7–10: UAT discovers that finance, sales, and operations each believed different rules. Leadership says freeze scope, “fix after launch.”
Go-live: The system works for the happy path. Exceptions flood WhatsApp groups. Excel returns. Adoption metrics look fine because people log in, then do real work outside the tool.
Year 2: A “stabilization” project becomes a second transformation. Cost exceeds the original build. Trust is gone.
McKinsey’s classic pitfalls still apply in 2026: unclear goals, weak “why,” activity theater instead of outcomes, and change that is not sustained. Culture remains a bigger obstacle than technology, organizations that invest in cultural change see far higher success rates than those that only buy tools.
Nearly two-thirds of employees resist organizational change to some degree (Gartner). That resistance gets worse when the new system encodes unclear, unstable rules. People are not resisting “digital.” They are resisting confusion.
The Real Reason, Said Clearly
Digital transformation projects fail because organizations try to digitize ambiguity.
Stakeholders who cannot articulate what they need create ambiguous targets. Teams who say “update later” convert ambiguity into code, config, and contracts. Once live, ambiguity becomes expensive permanence.
Technology did not fail. Clarity failed. Courage to decide failed. Governance of debt failed.
- Goals written as technologies (“implement AI,” “move to cloud”)
- Success = go-live date, not a business metric
- Every workshop ends with “to be confirmed”
- Different leaders describe different futures for the same process
- Vendors are asked to “propose the best practice” with no constraints
- “Temporary” customizations with no retirement date
- Phase-2 integrations that fund no owner
- Workarounds documented as training tips
- Nobody can estimate the cost of changing a core workflow
- Roadmap full of enhancements that are actually unfinished foundation
What Actually Works Instead
You do not need a perfect 5-year blueprint. You need decisive slices.
1. Force outcome clarity before build velocity
Translate slogans into measurable operating changes:
- “Reduce order cycle time from 4 days to 1”
- “Cut manual invoice touches by 60%”
- “One customer record across sales and finance”
If stakeholders cannot choose metrics, they are not ready to choose software.
2. Separate undecided from deferrable
Some things can wait. Core process rules, data ownership, access model, and system-of-record boundaries usually cannot.
Write a kill list: decisions that must be made before sprint N, or the project pauses. Pausing is cheaper than a fake go-live.
3. Ban “update later” without a dated debt ticket
Every temporary workaround needs:
- Owner
- Expiry date
- Risk if it remains
- Budget line for removal
No owner + no date = not temporary. It is a permanent design choice made in denial.
4. Redesign the process before you decorate it with tech
Automating a broken process produces faster brokenness. Sequence matters: problem → process → governance → technology.
5. Measure adoption as behavior, not logins
Track whether the new system replaced the old path. If Excel still wins the critical path, transformation has not occurred, only installation has.
6. Prefer incremental irreversible progress over big-bang theater
Big bang replacements often fail because they demand every stakeholder to know everything at once. Staged rollouts force learning while the blast radius is still small, and they make deferred bombs visible earlier.
Frequently Asked Questions
Yes in spirit. Multiple sources still cite roughly 70% missing objectives, while Gartner’s more precise framing is that only about 48% of digital initiatives meet or exceed business outcome targets. Bain has reported even higher rates of missed ambitions. The exact percentage varies by definition of “failure,” but the directional story has not flipped.
It is diagnosing a capability gap, not assigning villains. Most stakeholders were never trained to design target operating models. Transformation leadership must help them decide, with options, trade-offs, and consequences, instead of accepting vague wishes as requirements.
Agile ships small increments of validated value. “Update later” often means shipping unresolved foundations and hoping future budget will rewrite production reality. One reduces risk. The other schedules it.
Ask: What business metric must move? What process will be different on Monday after go-live? Which decisions are we refusing to defer? Who owns each temporary workaround and when does it die? If those answers are fuzzy, the project is already at risk, regardless of the tech stack.
Closing Thoughts
The market will keep selling platforms, AI copilots, and “transformation accelerators.” Some of them are useful. None of them can compensate for stakeholders who do not know what they need, or for leaders who postpone hard decisions under the soft language of later.
The real reason digital transformation projects fail is painfully ordinary: we digitize confusion, then act surprised when the system becomes a museum of unfinished choices.
If you are mid-program right now, audit every “temporary” item on your backlog. Put expiry dates on them. Force the undecided process rules into daylight. That bomb is either disarmed in the next quarter, or it detonates in production when you can least afford it.
Reference
- BCG, We Found the Real Reason 70% of Transformations Fail (May 2026)
- Gartner, Only 48% of Digital Initiatives Meet or Exceed Business Outcome Targets
- FT / TeamViewer partner content, 70% of transformation projects fail
- California Management Review, Technical Debt Is Killing Digital Transformation (2025)
- PM World Journal, The Challenge for 2026: Redefining Project Success
Images from Unsplash, free to use under the Unsplash License.