Digital Transformation Fails in the Org Chart, Not the Codebase

Large modernisation programmes fail regularly, and the reasons are remarkably consistent. It is almost never that the software could not be built. Read the retrospectives and the same handful of causes appear: nobody owned it, the incentives worked against it, the new process was the old process with a new interface, and the system it replaced was never turned off.

Technology is the part these programmes are best equipped to handle. It is everything around it that goes wrong.

One owner, with the authority to decide

A steering committee is not an owner. It is a forum for registering objections, which is useful, but it cannot make a decision quickly and it cannot be held responsible for one.

Successful programmes have a single person whose job is this outcome, who can settle disputes between departments without escalating, and who is available continuously rather than fortnightly. Where that person doesn't exist, the programme drifts toward whoever pushes hardest, and the design becomes a negotiated compromise rather than a coherent system.

Incentives beat announcements, every time

If the new system is slower for the team expected to adopt it, they will not adopt it. This is not resistance to change; it is a rational response to being asked to do more work for someone else's reporting.

Ask early and specifically: who does this make faster, and who does it make slower? There is almost always someone in the second group- frequently the people doing the data entry that produces someone else's dashboard. If their workload increases and nothing else changes for them, the data quality will decline until the reports become untrustworthy, and everyone will blame the software.

Fix it in the design or fix it in the incentives. Do not fix it in a memo.

Migrating the process, not just the data

The most common quiet failure: the new system faithfully reproduces the old workflow, including the steps that existed only because of what the old system couldn't do.

Approval chains built around a limitation removed a decade ago. Fields that are mandatory because a report needed them in 2016. A reconciliation step that exists because two systems disagreed- two systems that are both being replaced.

The migration is the one moment when questioning those steps is politically viable. Skip that conversation and you have spent a considerable sum to preserve your constraints in a modern technology stack.

Training is not a launch event

A two-hour session the week before go-live is a formality, and everyone attending knows it. People learn a system by using it on work that matters, with someone available when they get stuck.

That means an overlap period, realistic practice data, and identified people in each team who learned it first and can answer questions without a ticket. It is more effort than a launch event. It is also the difference between adoption and a workaround culture that hardens within a month.

Decommission, or you will run both forever

The final step is the one most often deferred: turning the old system off.

While it stays available, some processes will keep using it, some data will keep being written to it, and you will pay for both systems, maintain both, and reconcile between them indefinitely. The transformation stays permanently at ninety percent.

Set the shutdown date at the start of the programme, not at the end. Publish it. Treat it as the actual completion criterion- because a modernisation that ends with two systems running has, in every measurable sense, added one.