Why big digital transformation projects fail in mid-sized companies

The script is always the same, and anyone who works inside companies recognises it from the first scene. One day management decides it is time for "the digital transformation". Three ERP systems are evaluated, the most complete one wins, a project worth many months and many tens of thousands of euros is signed. At the kickoff everyone is optimistic. A year later the project is late, the scope has been cut twice, half the company still works the way it always did and the other half keeps two systems alive at once, old and new, entering data twice. Someone starts saying "the new system just isn't right for us".

It is not bad luck, and usually it is not the vendor's fault either. The format is wrong for how a mid-sized company actually works.

Three reasons the big project fails

First: a mid-sized company cannot stop to be digitalised. The people who are supposed to learn the new system, write requirements and run the tests are exactly the same people who keep daily operations going. The big project asks them to hold a second job for a year, and the second job always loses.

Second: trust is a resource that runs out. A project that promises value "once everything is ready" asks the company to believe for twelve or eighteen months without seeing anything. Operational trust lasts much less: after a few months without results, every meeting becomes a defence of the project instead of a step forward.

Third: requirements written up front lie. Not out of bad faith: because a company's real knowledge does not live in documents, it lives in the hands of the people who do the work. The exception made "only for that customer", the step that has existed for twenty years and nobody remembers why. These things only surface when people use something concrete, never in an analysis meeting. The big project discovers them when the system is finished, when fixing them costs the most.

The alternative: one process at a time

The method I have used for years turns the format upside down. You pick one single process, the one that hurts most: a schedule that never adds up, an archive overflowing, a regulatory deadline. You solve it in a few weeks, with a small concrete tool, and you put it immediately in the hands of the people who really use it. Not a demo prototype: something that is part of the job from Monday morning.

Then two things happen. The first is that people, watching a real problem disappear, change their attitude: the digital project stops being a threat and becomes something worth having. Internal champions appear, the ones who ask "couldn't we automate this too?". The second is technical: the solution to the first process becomes the building block of the second. Same data foundation, same records, same access control: every new piece rests on what is already there, and the system grows integrated instead of growing as islands.

Artificial intelligence, in this journey, is not the starting point: it is a tool that comes in once the process is clear and the data is there. First you bring order, then you automate what is ordered. Doing the opposite, buying "AI" hoping it will fix the disorder, is the big project under another name.

The six-year proof

I did this, rather than theorise it, in an industrial company of about a hundred employees. We started with logistics: route planning, a problem that hurt every single morning. Then site safety compliance. Then the most complex, regulated paperwork. Every step in production before the next one started, every solution resting on the previous one. Six years later those building blocks are a single platform used daily by about a thousand people, employees, customers and partners, maintained by an internal team that grew along the way. No big bang, no year on hold, no system rejected by its users. And no moment when the company had to take anything on faith: every step paid the trust for the next one.

The objections I always hear

"But this way you never get the big picture." The big picture is needed, but it is an architectural design: it lives in the head and plans of whoever leads the journey, and it is updated with every building block. Confusing vision with the mega-project is the mistake that generates the script of the first scene.

"What about our legacy ERP?" You do not throw it away. You integrate it: new systems talk to it, data stays in sync, and what works keeps working while everything else grows around it. Replacing the legacy is almost always a luxury for large enterprises.

"Isn't one process at a time slower?" It is slower to reach "the end", which does not exist anyway: a living company is never finished. It is much faster at returning value: weeks instead of years, and something new in production every month. Between a journey that pays from day one and a project that promises for later, the economics are not even close.

What to take home

Three questions to pick the first building block: where is the most time lost? where do mistakes happen most often? what is regulated and cannot go wrong? The process that answers two out of three is the one to start from.

And one single criterion to judge any digitalisation proposal that lands on your desk: how much time passes before someone in the company uses something new? If the answer is more than a few months, it is the wrong format, whatever the logo on the brochure.

Want to find the first building block in your company? Let's talk.