We've been called in to rescue enough stalled rollouts to notice a pattern: the software is very rarely the reason a digital transformation project fails. The reason is almost always one of these six boring, avoidable causes.
1. Nobody senior actually owns it
A project with an enthusiastic mid-level champion but no budget authority or organisational weight behind them stalls the moment it hits its first real obstacle — a department head who won't change their process, a budget line that needs sign-off. Transformation projects need a named senior owner who can clear obstacles, not just a project coordinator who can chase them.
2. Staff were told, not asked
The single most predictable failure pattern: management selects a system, announces a go-live date, and staff meet the software for the first time in a training session two weeks before launch. People who feel a system was imposed on them find every reason to keep using the old spreadsheet "just until things settle." Involve the actual users early enough that their objections shape the build — not so late that objections just become resistance.
3. Everything changed on the same day
Replacing five paper processes with one system, all switching over on the same launch date, means a mistake anywhere breaks everything at once — and gives every sceptic in the building a story to tell. Phase the rollout. Get one process solid, visibly working, and trusted before adding the next. Momentum from an early win carries the harder changes that follow.
4. Training was a single afternoon
A two-hour training session the week of launch is not training, particularly for staff who've used the same paper process for a decade. Budget for training as an ongoing line item, not a one-off event — refreshers a month in, a written quick-reference guide, and a named person staff can actually ask when they're stuck (not "check the manual").
5. Nobody defined what "success" meant
Without an agreed measure — reporting time cut from ten days to one, fee collection up by a specific margin, a queue eliminated — there's no way to know if the project actually worked, and no story to justify the disruption it caused. Agree the metric before the build starts, not after go-live when someone asks "was this worth it?"
6. Support ended at go-live
The real test of any new system isn't launch day, it's week six, when the first edge case appears that nobody anticipated and the vendor has moved on to the next client. Systems that survive are the ones with someone accountable for fixing what breaks and adjusting what doesn't quite fit, for months after the launch party is over.
How we phase this with clients
Every engagement we run for a digital transformation project starts by naming the senior owner, agreeing the success metric, and mapping which process moves first — before a single screen gets designed. It's less exciting than talking about the software, and it's the part that actually determines whether the project survives contact with your organisation.