The statistic repeated across the industry is that most digital transformation projects don't meet their objectives. The exact number varies by who's measuring and what counts as failure, but the underlying observation holds: a lot of money gets spent on systems nobody ends up using.
What's interesting is that the causes are almost never technical.
Cause 1: the system works and nobody uses it
The most frequent and the most frustrating, because from outside the project looks successful. The software runs, it does what the contract said, it shipped on time. And six months later the team is still on the spreadsheet.
The real reasons are usually three:
They weren't part of the design. Nobody asked the person who runs the process daily, and the system took the shape imagined by someone who never did the job.
Nobody explained what each person gains. The benefit communicated was the company's — traceability, control, data — which does nothing for the person entering orders.
The system doesn't handle the exceptions. And since the real process is full of exceptions, the tool doesn't help them work.
How to avoid it: involve operators from discovery, not from training. And when you do discovery, push on exceptions: "and when does it not happen that way?" That's where the real process lives.
Cause 2: scope inflated until it became impossible
It starts as "a system to manage orders". By the third meeting someone suggests that while we're at it we could add inventory. Then HR asks whether vacation tracking could be included. A month in, the project is an ERP.
Nobody decided that. It accumulated, and each addition seemed reasonable on its own.
The result is a project that takes a year, where nobody sees anything working until the end, and which by launch no longer matches the company that asked for it.
How to avoid it: fix phase one's scope and treat everything new as phase two. You don't have to say no; you have to say "later". And ask for partial deliveries every one or two weeks — the best antidote, because it forces something to be finished at all times.
Cause 3: the data was worse than everyone thought
The project moves along fine until migration. Then it turns out the same customer is recorded four different ways, dates come in three formats, nobody knows what the "OBS2" column means and 15% of records have a phone number in the email field.
The cleanup wasn't quoted, it eats weeks, and the project enters its first crisis.
How to avoid it: have historical data migration in the budget from the start — 10 to 15% of total in a healthy project — and have someone look at a real sample of the data before the price closes. Half an hour looking at the actual spreadsheet prevents the whole problem.
Cause 4: there's no internal owner
The vendor asks how a rule should work and nobody answers, or three people answer differently. Every decision takes a week. The project stretches without anyone doing anything wrong.
How to avoid it: designate one person in your company as project owner. They don't need to be technical; they need to know the operation and have authority to decide how work will be done going forward. Without that authority, the project stalls at every fork.
Cause 5: automating before digitizing
An automation tool gets bought, or an AI agent requested, for a process still living on paper and in messages. There's nothing to automate because there's no structured data.
Money gets spent, nothing happens, and the lasting impression is "this AI thing doesn't work for us".
How to avoid it: digitize first, automate second. Once the order arrives through a system instead of a message, an agent can classify it, notify the warehouse and build the invoice. Not before.
Cause 6: the old way got switched off too soon
The new system launches on a Monday and the spreadsheet gets retired the same day. Tuesday the first problem appears and there's nowhere to go back to. Operations suffer, the team loses confidence, and that confidence doesn't come back easily.
How to avoid it: parallel operation for three or four weeks. Data goes into both and results get compared. Old gets retired when the numbers match, not when the calendar says so.
Cause 7: it was treated as an IT project
It gets delegated to "the one who's good with computers" and leadership disengages until delivery. But digitizing means changing how people work, and that can't be led by someone without authority over how people work.
How to avoid it: give the project a sponsor with real weight. Not to attend every meeting: to unblock what needs unblocking and to back the change when it creates friction.
Five early warning signs
If you're mid-project, check these:
- More than three weeks without seeing something working. Not mockups: the real system, even if parts are missing.
- New requirements every meeting with nothing shipping in exchange.
- The future users have never been in a conversation.
- Nobody has looked at the data to be migrated yet.
- There's no date and no criteria for switching off the old way.
Any one of the five is a reason to stop a meeting and recalibrate. All five together is a reason to rethink the project.
If it already went wrong
The first question is whether the problem is technical or adoption, because the fixes are opposite.
If the system is badly built — it crashes, it's slow, core pieces are missing — you need an honest technical audit to determine what's salvageable and what should be rebuilt. From USD 1,500, and it saves you from rewriting something recoverable.
If the system is fine but nobody uses it, don't rewrite it. The problem is in the process and the people, and it's solved by re-examining how they actually work, adjusting the system for the exceptions that were missed, and training properly. Considerably cheaper than starting over, even if less tempting.
What the successful ones have in common
Looking at projects that finish and get used, the pattern repeats:
- They started with one process, not all of them.
- Operators participated from the beginning.
- There were partial deliveries you could touch.
- Data was cleaned and migrated seriously.
- Parallel operation happened before switching off the old way.
- Someone at the company owned the project and could decide.
None of those six is technical. Which is, in the end, the conclusion.
If you have a project underway that doesn't feel right, or one that went wrong and you're not sure whether to rescue it, a technical audit usually clears things up. And if you're about to start one, tell us about it before it inflates.
Frequently asked questions
What's the most common reason a new system goes unused?+
Adoption, not technology. The system works but the team keeps working the old way — almost always because they weren't part of the design, because nobody explained what they personally gain, or because the system doesn't handle the exceptions in the real process and therefore isn't useful to them.
How do I spot early that a project is going wrong?+
Three early signs: more than three weeks without seeing something working, new requirements appearing every meeting with nothing shipping in exchange, or the future users never having been part of a single conversation. Any of the three is a moment to stop and recalibrate.
Whose fault is it when a software project fails?+
Almost never one side's. Vendors typically fail by not insisting on bounded scope and not involving real users. Clients typically fail by not assigning an internal owner with authority and by requesting changes without accepting the cost. What's useful isn't assigning blame but recognizing the signs early.
Can a project that already went wrong be recovered?+
Sometimes. The first thing is determining whether the problem is technical or adoption, because the fixes are opposite. If the system is well built but nobody uses it, it doesn't need rewriting: it needs work on process and training, which is considerably cheaper.
Want this working in your company?
At Deepyze we turn manual processes into systems that work on their own: AI automation, web and mobile apps, and custom software. Tell us your case and you will have a concrete proposal within 24 hours.
Sin compromiso · Respuesta en 24 hs · Equipo en tu mismo huso horario