The digital paradox: investing more and getting less
The figures are compelling and, at this point, hard to ignore. According to recurring studies by McKinsey, BCG and Forrester, between 70% and 84% of digital transformation projects fail to achieve their intended objectives. We are not talking about mediocre projects run by inexperienced teams: we are talking about initiatives with multi-million budgets, backed by board committees and led by senior profiles.
The paradox is clear. Companies invest more than ever in technology, but the results don't follow. And the fundamental reason lies not in the tools, but in the approach. Digital transformation is not a technology project; it is a business project enabled by technology. When that order of priorities is reversed, failure is almost inevitable.
At SEITON we have been accompanying organisations through change processes for over 25 years, and we have identified clear patterns that separate successful projects from those that fall short. In this article we break them down with the intention of offering a useful map for executives and transformation leaders.
The paradox is clear. Companies invest more than ever in technology, but the results don't follow. And the fundamental reason lies not in the tools, but in the approach. Digital transformation is not a technology project; it is a business project enabled by technology. When that order of priorities is reversed, failure is almost inevitable.
At SEITON we have been accompanying organisations through change processes for over 25 years, and we have identified clear patterns that separate successful projects from those that fall short. In this article we break them down with the intention of offering a useful map for executives and transformation leaders.
Cause 1: Absence of clear strategy and vision
The most frequent error we detect in our consulting practice is the absence of a clear strategy linking digital transformation to business objectives. Many organisations start digital projects because you have to digitalise, because the competition is doing it or because a technology vendor presented a convincing demo. But when you ask what for, the answers are vague.
A digital transformation without strategy is like renovating a house without blueprints: you might end up with a beautiful kitchen where you needed a warehouse. Before choosing any tool, it is essential to answer three questions:
Without this prior strategic diagnostic exercise, companies end up accumulating disconnected tools, data in silos and frustrated teams. Technology does not solve problems that have not been properly defined.
A digital transformation without strategy is like renovating a house without blueprints: you might end up with a beautiful kitchen where you needed a warehouse. Before choosing any tool, it is essential to answer three questions:
- What are the critical business processes and where are the current bottlenecks
- What data do we need to capture and exploit to make better decisions
- What organisational capabilities must we develop to sustain the change
Without this prior strategic diagnostic exercise, companies end up accumulating disconnected tools, data in silos and frustrated teams. Technology does not solve problems that have not been properly defined.
Cause 2: Ignoring change management and people
The second cause of failure is, paradoxically, the most human. Organisations systematically underestimate the impact that a digital transformation project has on people, their routines and their way of working. The software is purchased, the system configured, the team trained for two afternoons... and everything is expected to work.
Change management is not a project add-on: it is the project. We have seen technically impeccable implementations fail because operational teams reject the new system, use it partially or return to spreadsheets within weeks. The reasons are understandable: fear of losing relevance, lack of understanding of the why, insufficient training processes or absence of internal leaders to drive adoption.
In our methodology, change management starts on day one, not when the system is deployed. We work with teams from the diagnostic phase, involve key users in solution design and establish ongoing support mechanisms. Because the best tool in the world is worthless if the team using it hasn't made it their own.
Change management is not a project add-on: it is the project. We have seen technically impeccable implementations fail because operational teams reject the new system, use it partially or return to spreadsheets within weeks. The reasons are understandable: fear of losing relevance, lack of understanding of the why, insufficient training processes or absence of internal leaders to drive adoption.
In our methodology, change management starts on day one, not when the system is deployed. We work with teams from the diagnostic phase, involve key users in solution design and establish ongoing support mechanisms. Because the best tool in the world is worthless if the team using it hasn't made it their own.
Cause 3: Excessive focus on technology, not processes
It is the trap that even the most experienced companies fall into: believing that buying technology is synonymous with transforming. A state-of-the-art ERP is implemented, a CRM with artificial intelligence or a Business Intelligence platform with dozens of dashboards... but exactly the same inefficient processes that existed before are replicated.
Digitising a poorly designed process only makes it inefficient faster. This principle, which may sound obvious, is systematically violated. The reason is that process analysis and redesign is less flashy work than a technology demo, but infinitely more decisive for the final result.
At SEITON, every transformation project begins with a deep process diagnosis. We use methodologies such as BPMN, Value Stream Mapping and efficiency audits to understand operational reality before proposing any technology solution. Only when the process is optimised does it make sense to enable it with technology.
Digitising a poorly designed process only makes it inefficient faster. This principle, which may sound obvious, is systematically violated. The reason is that process analysis and redesign is less flashy work than a technology demo, but infinitely more decisive for the final result.
- Before automating, you must simplify
- Before measuring, you must define what matters to measure
- Before integrating systems, you must map real information flows
At SEITON, every transformation project begins with a deep process diagnosis. We use methodologies such as BPMN, Value Stream Mapping and efficiency audits to understand operational reality before proposing any technology solution. Only when the process is optimised does it make sense to enable it with technology.
Cause 4: Ungoverned data and measurement without criteria
Another recurring pattern: companies accumulate data from multiple sources, but have no data governance strategy. Systems don't communicate with each other, each department manages its own metrics, KPI definitions vary depending on who consults them and nobody has the complete picture.
The data economy demands discipline. It's not about having more data, but having the right data, clean, accessible and with a clear purpose. We have found organisations with more than 15 dashboards that nobody consults because they don't trust the figures. The problem was not the BI tool, but the absence of a coherent data model and governance that ensures quality and consistency.
Our recommendation is clear: before building a data warehouse or deploying Power BI, you must define the data architecture, establish data owners by functional area, document quality rules and create a shared metrics dictionary. This preliminary work, less glamorous but absolutely critical, is what differentiates companies that truly make data-driven decisions from those that merely claim to.
The data economy demands discipline. It's not about having more data, but having the right data, clean, accessible and with a clear purpose. We have found organisations with more than 15 dashboards that nobody consults because they don't trust the figures. The problem was not the BI tool, but the absence of a coherent data model and governance that ensures quality and consistency.
Our recommendation is clear: before building a data warehouse or deploying Power BI, you must define the data architecture, establish data owners by functional area, document quality rules and create a shared metrics dictionary. This preliminary work, less glamorous but absolutely critical, is what differentiates companies that truly make data-driven decisions from those that merely claim to.
The SEITON approach: processes first, technology second, data always
After more than two decades and 200 projects delivered across sectors as diverse as tourism, healthcare, engineering and business organisation, we have consolidated an approach we call Processes-Technology-Data. It is not a rigid framework, but a working philosophy that adapts to each organisation's reality:
The key is not in the technology you choose, but in how you integrate it into your operations, with your teams and oriented to your data. That is the difference between a project that fails and one that transforms. If you are planning a digital transformation initiative and want to avoid being part of that 80%, let's talk.
- Phase 1 - Strategic diagnosis: We understand the business, map critical processes, identify inefficiencies and define measurable objectives linked to business outcomes
- Phase 2 - Solution design: We redesign processes before selecting technology. We define the data architecture and KPIs that will guide measurement
- Phase 3 - Supported implementation: We deploy the solution with integrated change management, continuous training and operational support
- Phase 4 - Ongoing management: We don't disappear after delivery. We monitor results, adjust processes and evolve the solution with the business
The key is not in the technology you choose, but in how you integrate it into your operations, with your teams and oriented to your data. That is the difference between a project that fails and one that transforms. If you are planning a digital transformation initiative and want to avoid being part of that 80%, let's talk.
