I have led AI and ERP transformations at Novartis, and I will tell you what the vendors never do: the technology is almost never the hardest part. Roughly 70% of transformation programs fail to hit their goals — and when I look under the hood of the failures, the software usually worked fine. The people around it quietly opted out.
That number gets quoted so often it has become background noise. It should not be. Behind it are budgets burned, credibility lost, and talented teams who conclude that "change" is just something done to them. The good news: the failure pattern is predictable, which means it is fixable.
The real point of failure is not the platform
When a go-live disappoints, the post-mortem almost always blames scope, data quality, or integration. Those are symptoms. The root cause is that adoption was treated as a training event at the end, not a design constraint from the start.
Here is the uncomfortable math. A tool can be technically perfect and still deliver zero value if people route around it. I have seen a flawless module sit at 30% real usage six months post-launch while the old spreadsheet quietly ran the business. The system worked. The change did not.
You do not get the ROI of the software you bought. You get the ROI of the software people actually use.
Why people opt out — and it is rational
People rarely resist change because they are lazy or afraid of technology. They resist because, from where they sit, the change is a bad trade: more risk, more scrutiny, and no obvious upside for them personally.
The missing ingredient is psychological safety — the belief that you can admit "I don't understand this yet" or "this new process is broken" without looking incompetent. When that safety is absent, people hide their confusion. Hidden confusion becomes silent workarounds. Silent workarounds become your 70% statistic.
The People-First Fix: a framework I actually use
This is not theory. It is the sequence I run on every program, and it fits on one page.
1. Name the "from → to" in human terms
Before any config, I write one sentence per affected role: what their day looks like today, and what it looks like after. If I cannot articulate a concrete win for that person, I do not yet have a change — I have a rollout. Fix the trade before you fix the timeline.
2. Recruit skeptics, not champions
Everyone parades their enthusiasts. I do the opposite: I put the loudest skeptic in the design room early. Skeptics surface the real objections while they are still cheap to solve, and when a known skeptic converts, they persuade peers far more than any executive memo.
3. Make safety visible with a "confusion budget"
- Leaders go first: I ask sponsors to say publicly, "I got this wrong last time — here is what we changed." One honest admission from the top buys more candor than a dozen surveys.
- Reward the flag, not the silence: the person who reports a broken step is doing quality control for free. Thank them by name.
- Normalize "not yet": "I don't know how to do this yet" is a status update, not a failure.
4. Measure adoption like you measure uptime
Most programs track go-live date and budget. I track a small set of leading indicators from week one: active-usage rate, workaround frequency, and time-to-competence per role. If usage stalls, I know in days, not quarters. What you do not measure, you cannot rescue.
5. Close the loop out loud
When someone raises a problem and I fix it, I broadcast the fix and credit the source. Nothing accelerates adoption like proof that speaking up changes the system. It turns a passive audience into co-owners.
What changes when you lead this way
On the programs where I front-loaded people over platform, the shift was concrete: adoption curves that used to sag for months instead crossed 80% real usage within weeks, support tickets dropped because problems surfaced early, and — the part executives feel most — the business stopped running a shadow process in parallel.
None of this required better software. It required treating trust as infrastructure: something you design, budget, and maintain, exactly like the tech stack.
The bottom line for leaders
If your next transformation is at risk, do not start by auditing the architecture. Start by asking your teams a simpler question and actually listening to the answer: "What would make this genuinely better for you — and what are you afraid to tell me?" The organizations that can hear that answer are the 30% that win.
So before your next go-live, ask yourself: have you engineered the technology, or have you engineered the trust?
Originally published on cedricbignet.com. I'm Cédric Bignet — AI & ERP Change Management expert at Novartis and founder of AInspire.
Top comments (0)