A company decides to modernize its operations. It picks a well-known software, signs with an integrator, sets a launch date. Twelve months and several hundred thousand dollars later, the system does not do what it was supposed to do. The team works around the tool, falls back on its old spreadsheets, and leadership wonders where the money went.
This scenario is not the exception. It is the norm.
According to Gartner, more than 70% of ERP implementations never meet the business goals that justified the investment in the first place. And this is not an ERP-specific problem. It is a problem of approach, and it touches almost every category of technology.
The Numbers Are Constant, No Matter the Technology
When you look at the three families of solutions companies adopt most, the picture repeats itself.
ERP. More than 70% of projects miss their original business goals, and only about 30% are delivered on time and on budget. When a project goes off the rails, the cost overruns are not marginal: in manufacturing, they average more than 200% of the initial budget.
CRM. The failure rate hovers around 55%, according to research that defines failure as a deployment that did not reach its objectives. The commonly cited range runs from 50% to 70%.
Generative AI. This is the most striking number. In 2025, the MIT report (Project NANDA) established that roughly 95% of enterprise generative AI pilots produce no measurable impact on profitability, despite 30 to 40 billion dollars poured into these initiatives.
Three different technologies, three decades of evolution between them, and yet the same result: a majority of projects that never hit their target.
The Real Problem Is Not the Technology
This is where the data becomes useful. When you look for why these projects fail, it is almost never the software at fault.
On the CRM side, more than 60% of failures are tied to people and process. Fewer than 10% come from a genuine technical fault in the software. On the ERP side, more than 60% of failures trace back to the early phases of the project, the ones where you define requirements and map processes. And MIT is categorical on AI: the divide between projects that succeed and those that fail is not explained by the quality of the models, but by the approach.
In other words, the error happens well before go-live. It happens at the moment of purchase.
Most projects start backwards. You choose the solution before you have understood the problem. You sign for a tool because it is well known, because a competitor uses it, or because a demo was convincing. Then you ask the team to bend its way of working to fit the mold of the software. That is exactly the inverse of what works.
The Three Mistakes That Derail a Project
Buying before diagnosing. When more than 60% of ERP failures are rooted in the requirements phase, the message is clear. Without an honest map of your current workflows, you are buying a solution to a problem you have not yet named.
Forcing the team to adapt to the tool. Software nobody uses is worth nothing, regardless of its features. Low user adoption comes up constantly as a cause of failure. The right sequence is to make the solution adapt to the reality of the team, not the other way around.
Moving forward without realistic expectations. Cost overruns that reach several times the starting budget are not accidents. They come from fuzzy expectations, a poorly defined scope, and hidden costs that were never framed. Without a clear picture of what is included, what is not, and what it will cost, surprises are guaranteed.
Our Method: See, Sort, Act
At HUBBVEE, we never start with the software. We start with reality. Our method has three movements, and it answers the documented causes of failure directly.
See. We map your workflows without a filter. We look at how work actually gets done today, not how it is supposed to get done on paper. This step, the one most failed projects skip, is precisely the one that determines success.
Sort. We prioritize by real impact on your business. Not all features are equal, and not all problems deserve the same attention. We separate what truly matters from what is incidental, and we set realistic expectations before a single dollar is committed.
Act. We execute with a structured plan, where the solution adapts to your team. We choose the technology based on the diagnosis, not the other way around, and we support adoption so the tool actually gets used.
Three Moments Where We Can Step In
A technology project does not need to be in crisis for us to be useful. We intervene at three distinct moments.
Before the purchase: getting it right from day one. This is the ideal moment. We diagnose your needs, map your processes, and define the scope before you sign anything. You choose your solution knowing exactly what it has to accomplish and what it should cost. It is the most economical way to avoid becoming part of the 70%.
During the project: limiting the damage. A project already underway that starts to drift is not a lost cause. We step in to reframe the scope, realign the solution with your real needs, and regain control of costs before the bill becomes unrecoverable.
After a failure: recovering what can be saved. An abandoned project or a system nobody uses often holds more value than you would think. We diagnose what went wrong, identify what is salvageable, and build a recovery plan. In most cases, the technology was adequate. What was missing was the approach.
The Technology Was Never the Problem
The numbers all tell the same story. The tools work. It is the projects that fail, for lack of an honest diagnosis, a clear-eyed prioritization, and a plan that respects the reality of your team.
See, Sort, Act. That is the difference between buying software and succeeding at a project.
Are you considering a technology investment, or trying to save a project that is drifting? Let's talk before the numbers apply to you.
Let's talk about your project.
Sources
- Gartner, cited by ECI Solutions, The $2 million mistake: why 70% of ERP implementations fail (2025): more than 70% of ERP implementations miss their original business goals.
- CatalistIQ / Gartner and CIO.com data: roughly 30% of ERP projects delivered on time and on budget; more than 60% of failures linked to the requirements-gathering phases.
- Godlan, ERP Implementation Failure Statistics (2025): average cost overruns above 200% in discrete manufacturing.
- Johnny Grow, The CRM Failure Rate is 55% in 2025: CRM failure rate of 55%, defined as a deployment that did not reach its objectives.
- Vantage Point, Why 70% of CRM Projects Fail: more than 60% of CRM failures tied to people, fewer than 10% to technical faults in the software.
- MIT Project NANDA, The GenAI Divide: State of AI in Business 2025: roughly 95% of enterprise generative AI pilots show no measurable impact on profitability; 30 to 40 billion invested; cause attributed to the approach, not the quality of the models.
Une entreprise décide de moderniser ses opérations. Elle choisit un logiciel reconnu, signe avec un intégrateur, fixe une date de mise en ligne. Douze mois et plusieurs centaines de milliers de dollars plus tard, le système ne fait pas ce qu'on attendait de lui. L'équipe contourne l'outil, retourne à ses anciens fichiers, et la direction se demande où l'argent est passé.
Ce scénario n'est pas une exception. C'est la norme.
Selon Gartner, plus de 70 % des implantations ERP n'atteignent jamais les objectifs d'affaires qui justifiaient l'investissement au départ. Et ce n'est pas un problème propre aux ERP. C'est un problème d'approche, et il touche presque toutes les catégories de technologie.
Les chiffres sont constants, peu importe la technologie
Quand on regarde les trois familles de solutions que les entreprises adoptent le plus, le portrait se répète.
ERP. Plus de 70 % des projets n'atteignent pas leurs objectifs d'affaires initiaux, et environ 30 % seulement sont livrés dans les délais et le budget prévus. Quand un projet dérape, les dépassements de coûts ne sont pas marginaux : dans le secteur manufacturier, ils atteignent en moyenne plus de 200 % du budget initial.
CRM. Le taux d'échec tourne autour de 55 %, selon des recherches qui définissent l'échec comme un déploiement qui n'a pas atteint ses objectifs. La fourchette généralement citée va de 50 % à 70 %.
IA générative. C'est le chiffre le plus frappant. En 2025, le rapport du MIT (Project NANDA) a établi qu'environ 95 % des projets pilotes d'IA générative en entreprise ne produisent aucun impact mesurable sur la rentabilité, et ce, malgré 30 à 40 milliards de dollars investis dans ces initiatives.
Trois technologies différentes, trois décennies d'évolution entre elles, et pourtant le même résultat : une majorité de projets qui n'atteignent pas leur cible.
Le vrai problème n'est pas la technologie
C'est ici que la donnée devient utile. Quand on cherche pourquoi ces projets échouent, ce n'est presque jamais le logiciel qui est en cause.
Du côté du CRM, plus de 60 % des échecs sont liés aux gens et aux processus. Moins de 10 % proviennent d'un problème technique réel du logiciel. Du côté de l'ERP, plus de 60 % des échecs remontent aux phases initiales du projet, celles où l'on définit les besoins et où l'on cartographie les processus. Et le MIT est catégorique sur l'IA : la fracture entre les projets qui réussissent et ceux qui échouent ne s'explique pas par la qualité des modèles, mais par l'approche.
Autrement dit, l'erreur arrive bien avant la mise en ligne. Elle arrive au moment de l'achat.
La plupart des projets démarrent à l'envers. On choisit la solution avant d'avoir compris le problème. On signe pour un outil parce qu'il est reconnu, parce qu'un concurrent l'utilise, ou parce qu'une démo était convaincante. Puis on demande à l'équipe de plier ses façons de faire pour entrer dans le moule du logiciel. C'est exactement l'inverse de ce qui fonctionne.
Les trois erreurs qui font dérailler un projet
Acheter avant de diagnostiquer. Quand plus de 60 % des échecs ERP sont enracinés dans la phase de définition des besoins, le message est clair. Sans cartographie honnête de vos flux de travail actuels, vous achetez une solution à un problème que vous n'avez pas encore nommé.
Forcer l'équipe à s'adapter à l'outil. Un logiciel que personne n'utilise ne vaut rien, peu importe ses fonctionnalités. La faible adoption par les utilisateurs revient constamment comme cause d'échec. La bonne séquence consiste à faire en sorte que la solution s'adapte à la réalité de l'équipe, et non l'inverse.
Avancer sans attentes réalistes. Les dépassements de coûts qui atteignent plusieurs fois le budget de départ ne sont pas des accidents. Ils découlent d'attentes floues, d'un périmètre mal défini et de coûts cachés jamais cadrés. Sans cadre clair sur ce qui est inclus, ce qui ne l'est pas et ce que ça coûtera, les surprises sont garanties.
Notre méthode : Voir, Trier, Agir
Chez HUBBVEE, on ne commence jamais par le logiciel. On commence par la réalité. Notre méthode tient en trois temps, et elle répond directement aux causes d'échec documentées.
Voir. On cartographie vos flux de travail sans filtre. On regarde comment le travail se fait réellement aujourd'hui, pas comment il est censé se faire sur papier. Cette étape, celle que la majorité des projets ratés escamotent, est précisément celle qui détermine le succès.
Trier. On priorise par impact réel sur votre entreprise. Toutes les fonctionnalités ne se valent pas, et tous les problèmes ne méritent pas la même attention. On sépare ce qui compte vraiment de ce qui est accessoire, et on définit des attentes réalistes avant que le moindre dollar ne soit engagé.
Agir. On exécute avec un plan structuré, où la solution s'adapte à votre équipe. On choisit la technologie en fonction du diagnostic, pas l'inverse, et on accompagne l'adoption pour que l'outil soit réellement utilisé.
Trois moments où on peut intervenir
Un projet technologique n'a pas besoin d'être en crise pour qu'on soit utiles. On intervient à trois moments distincts.
Avant l'achat : réussir dès le premier jour. C'est le moment idéal. On diagnostique vos besoins, on cartographie vos processus et on définit le périmètre avant que vous ne signiez quoi que ce soit. Vous choisissez votre solution en sachant exactement ce qu'elle doit accomplir et combien elle devrait coûter. C'est la façon la plus économique d'éviter de faire partie des 70 %.
Pendant le projet : limiter les dégâts. Un projet déjà lancé qui commence à déraper n'est pas une fatalité. On intervient pour recadrer le périmètre, réaligner la solution sur vos vrais besoins et reprendre le contrôle des coûts avant que la facture ne devienne irrécupérable.
Après un échec : récupérer ce qui peut l'être. Un projet abandonné ou un système que personne n'utilise contient souvent plus de valeur qu'on le croit. On fait le diagnostic de ce qui a mal tourné, on identifie ce qui est récupérable et on bâtit un plan de redressement. Dans la majorité des cas, la technologie était adéquate. Ce qui manquait, c'était l'approche.
La technologie n'a jamais été le problème
Les chiffres racontent tous la même histoire. Les outils fonctionnent. Ce sont les projets qui échouent, faute d'un diagnostic honnête, d'une priorisation lucide et d'un plan qui respecte la réalité de votre équipe.
Voir, Trier, Agir. C'est la différence entre acheter un logiciel et réussir un projet.
Vous envisagez un investissement technologique, ou vous tentez de sauver un projet qui dérape ? Parlons-en avant que les chiffres ne s'appliquent à vous.
Parlons de votre projet.
Sources
- Gartner, cité par ECI Solutions, The $2 million mistake: why 70% of ERP implementations fail (2025) : plus de 70 % des implantations ERP n'atteignent pas leurs objectifs d'affaires initiaux.
- CatalistIQ / données Gartner et CIO.com : environ 30 % des projets ERP livrés dans les délais et le budget ; plus de 60 % des échecs liés aux phases de cueillette des besoins.
- Godlan, ERP Implementation Failure Statistics (2025) : dépassements de coûts moyens supérieurs à 200 % en manufacturier discret.
- Johnny Grow, The CRM Failure Rate is 55% in 2025 : taux d'échec CRM de 55 %, défini comme déploiement n'ayant pas atteint ses objectifs.
- Vantage Point, Why 70% of CRM Projects Fail : plus de 60 % des échecs CRM liés aux gens, moins de 10 % à des problèmes techniques du logiciel.
- MIT Project NANDA, The GenAI Divide: State of AI in Business 2025 : environ 95 % des projets pilotes d'IA générative sans impact mesurable sur la rentabilité ; 30 à 40 milliards investis ; cause attribuée à l'approche et non à la qualité des modèles.
Frequently asked questions
Why do most ERP projects fail?
According to Gartner, more than 70% of ERP implementations never meet the business goals that justified the investment. The cause is rarely the software. More than 60% of ERP failures trace back to the early phases of the project, where requirements are defined and processes are mapped. The error happens at the moment of purchase, not at go-live: companies choose the solution before they understand the problem.
What is the failure rate of CRM and AI projects?
CRM project failure sits around 55%, with the commonly cited range running from 50% to 70%. For generative AI, the 2025 MIT Project NANDA report found that roughly 95% of enterprise GenAI pilots produce no measurable impact on profitability, despite 30 to 40 billion dollars invested. For CRM specifically, more than 60% of failures are tied to people and process, and fewer than 10% to a genuine technical fault in the software.
If the technology works, why do projects still fail?
Because most projects start backwards. They pick the solution before understanding the problem, sign for a tool because a competitor uses it or a demo was convincing, then ask the team to bend its workflow to fit the software. The three recurring mistakes are: buying before diagnosing, forcing the team to adapt to the tool, and moving forward without realistic expectations on scope and cost.
Can a failed or stalled tech project be saved?
Often, yes. An abandoned project or a system nobody uses usually holds more value than people assume. In most cases the technology was adequate and the approach was missing. HUBBVEE intervenes at three moments: before purchase to get it right from day one, during the project to recover a scope that is drifting, and after a failure to diagnose what went wrong and build a recovery plan from what is salvageable.
Questions fréquentes
Pourquoi la plupart des projets ERP échouent-ils ?
Selon Gartner, plus de 70 % des implantations ERP n'atteignent jamais les objectifs d'affaires qui justifiaient l'investissement. La cause est rarement le logiciel. Plus de 60 % des échecs ERP remontent aux phases initiales du projet, celles où l'on définit les besoins et où l'on cartographie les processus. L'erreur arrive au moment de l'achat, pas à la mise en ligne : on choisit la solution avant d'avoir compris le problème.
Quel est le taux d'échec des projets CRM et IA ?
Le taux d'échec CRM tourne autour de 55 %, avec une fourchette généralement citée de 50 % à 70 %. Pour l'IA générative, le rapport du MIT (Project NANDA) de 2025 a établi qu'environ 95 % des pilotes d'IA générative en entreprise ne produisent aucun impact mesurable sur la rentabilité, malgré 30 à 40 milliards de dollars investis. Côté CRM, plus de 60 % des échecs sont liés aux gens et aux processus, et moins de 10 % à un vrai problème technique du logiciel.
Si la technologie fonctionne, pourquoi les projets échouent-ils ?
Parce que la plupart des projets démarrent à l'envers. On choisit la solution avant de comprendre le problème, on signe pour un outil parce qu'un concurrent l'utilise ou parce qu'une démo était convaincante, puis on demande à l'équipe de plier ses façons de faire pour entrer dans le moule du logiciel. Les trois erreurs récurrentes : acheter avant de diagnostiquer, forcer l'équipe à s'adapter à l'outil, et avancer sans attentes réalistes sur le périmètre et les coûts.
Peut-on sauver un projet techno échoué ou qui dérape ?
Souvent, oui. Un projet abandonné ou un système que personne n'utilise contient généralement plus de valeur qu'on le croit. Dans la majorité des cas, la technologie était adéquate et c'est l'approche qui manquait. HUBBVEE intervient à trois moments : avant l'achat pour réussir dès le premier jour, pendant le projet pour récupérer un périmètre qui dérape, et après un échec pour diagnostiquer ce qui a mal tourné et bâtir un plan de redressement à partir de ce qui est récupérable.