I have watched a number of transformation programmes over the years — some I led, some I observed, some I inherited. The ones that failed rarely failed because the software did not work.
They failed because the organisation around the software did not change.
The comfortable mistake
Buying a platform feels like progress. There is a decision, a contract, a launch date, a project plan. It is visible, fundable, and reportable to a board.
Changing how three hundred people work is none of those things. It is slow, unglamorous, and difficult to show on a slide. So it gets underfunded relative to the technology it is supposed to support — and then everyone is surprised when adoption disappoints.
The system was never the hard part.
Four places transformations actually break
1. The new process is harder than the old one for the person doing it. Leadership sees the aggregate benefit — better data, fewer errors, faster reporting. The individual employee sees more clicks and an unfamiliar screen. If the new way is genuinely worse at the level of the person doing the work, they will find a workaround, and the workaround will become the real process.
The fix is to design with frontline staff, not for them. If the people using it daily have not shaped it, expect resistance that is entirely rational.
2. Incentives point in the old direction. If a team is measured on volume and the new system trades a little speed for much better data quality, the team will resist. Not out of stubbornness — out of self-preservation. Measure people on the old outcomes and they will optimise for the old outcomes.
3. Nobody owns it after launch. The project team disbands. The vendor moves on. The system enters a slow decline: workarounds accumulate, data quality drifts, and two years later someone proposes a transformation programme to fix the transformation programme.
A system needs a permanent owner with authority, not a temporary project manager.
4. Leadership does not use it. This one is underrated. If executives still ask for the manual spreadsheet, the organisation learns instantly that the new system is optional. Nothing you say in a town hall will override what people observe about what you actually rely on.
What tends to work
Sequence for early wins. Start where the pain is worst and the fix is clearest. Momentum is a real asset; nothing builds credibility like one team visibly getting their evenings back.
Overinvest in training, then invest again. One session before launch is not training. It is a formality. People need support at the moment of confusion, weeks in, when the initial energy has faded and the real questions arrive.
Keep a visible feedback loop. Staff will report friction if — and only if — they have seen previous reports acted upon. The first few fixes you ship in response to feedback determine whether you get any more.
Retire the old way deliberately. Running both systems “for a transition period” is how transitions become permanent. At some point, with adequate support and honest warning, the old path has to close.
The reframe
I have stopped thinking of these as technology programmes. A transformation is an organisational change that happens to involve software. The software is usually the most predictable component — it has documentation, a vendor, and a support line.
The people do not come with documentation. That is where the leadership work is, and it is not delegable.
Dr. Mohamed Mousa writes about financial services, technology, and leadership.