Why software implementations fail - and how to avoid it

Across the years of running my own companies I've seen roll-outs that worked and ones that stalled or quietly died. The difference was almost never the technology. It was how the project was run. Below I name the recurring causes of failure and show how I run an implementation to avoid them.

It's rarely the technology itself

The scale is large: according to international market studies (Panorama, Gartner), most roll-outs of large ERP systems fail to meet their goals - the figure quoted is 55-75% of projects. That's global data and applies mainly to large packages, but the causes recur clearly enough to be named and avoided. And almost none of them lies in the software itself.

Buying on the demo rather than the process

The most common mistake is choosing a system on the strength of a good sales demo rather than your own processes. The program looks great in the presentation, but it turns out your way of taking orders or planning production doesn't fit it. Then the fitting of the company to the tool begins - and that's exactly where the project starts to lose its footing.

Skipped analysis and too broad a scope

The second pattern is starting without a solid analysis of how the company actually works, combined with trying to roll everything out at once. The broader the scope at the start, the more can go wrong before anyone sees a first result. A big “all at once” project turns into a months-long slog where it's easy to overrun the budget and lose the team's patience.

A team no one asked

The third cause is human. When a system is decided on without talking to the people meant to use it, resistance appears, and the tool doesn't reflect the reality of the shop floor or the office. People then slip back to the old spreadsheets on the side, the company runs two parallel workflows, and the expensive system sits largely unused.

How I run an implementation so it works

I start with a conversation about the process. I tackle one area first that delivers a fast, visible result - I can stand up the first module in 14 working days and the full first project in 4-8 weeks. I build alongside the people who will use the system, so it reflects their real work. Further modules come in stages, next to day-to-day operations, and the code and data stay yours. That way there's a result at every stage, and the risk of one big, one-off disaster simply has nowhere to appear.

If you're planning an implementation and want to do it safely - let's talk for thirty minutes. I'll suggest which area to start with so the first result comes quickly.