Chaque année depuis 1994, le Standish Group publie son “Standish Group Chaos Report”, faisant un tour d’horizon très documenté de l’état de l’industrie du développement logiciel.
Les statistiques se basent sur l’analyse de plus de 50 000 projets dans le monde entier, dont le coût moyen de développement va de 434.000 USD pour une petite entreprise, à 2.322.000 USD pour une grosse organisation.
Note de BestOfBusinessAnalyst : cet article a été rédigé avant que j’ai eu connaissance d’un rapport plus récent du Standish Group (2015). Les derniers chiffres font état d’une amélioration du taux d’échec des projets, lequel tournerait à présent aux alentours de 71% grâce notamment à l’usage plus étendu des approches agiles. Mais il n’en reste pas moins que cela reste dramatiquement élevé et qu’il est indispensable d’en comprendre les causes racines pour tendre vers un chiffre acceptable…
Le rapport démontre, chiffres à l’appui, que la majorité de ces projets échoue, ce qui signifie que :
- 31,1% d’entre eux sont stoppés en cours de route et ne sont donc jamais déployés. Le Standish Group estime par exemple que les entreprises et agences gouvernementales américaines auraient perdu 81 milliards de dollars en 2015, rien que pour couvrir le coût de ces projets annulés !
- A côté de cela, 52,7% des projets dépassent de 189% leurs prévisions budgétaires, et bien davantage si l’on tient compte du coût des opportunités perdues. Au coût des projets annulés, il faudrait donc ajouter 59 milliards de dollars US correspondant aux surcoûts des projets déployés.
- Enfin, pour terminer sur une note positive, il existe tout-de-même des projets informatiques qui finissent dans les clous du point de vue du budget et des délais. Oui, mais… ils ne sont en moyenne que 16,2% à réussir ce challenge – les grandes entreprises atteignant d’ailleurs avec peine le seuil des 9%.
Bien entendu, si un projet informatique a comme objectif de mettre en place une nouvelle technologie, il y a toujours des risques qui peuvent expliquer un tel écart. Le problème, c’est qu’une grande partie de ces projets concernent des problématiques courantes et habituelles, que l’on rencontre depuis aussi longtemps que l’informatique existe en entreprise : renouvellement de licences, upgrades logicielles, mise en place d’un nouvel outil de comptabilité ou encore d’un système de saisie des commandes.
Le “Standish Group Chaos Report” a classé ses résultats de la manière suivante :
- Projet réussi (« Project success »): le projet a été achevé dans les temps et dans l’enveloppe budgétaire initialement prévue, et le logiciel comporte les fonctionnalités et fonctions demandées.
- Projet en difficulté (« challenged project ») : le projet a été achevé et est opérationnel. Néanmoins, il a dépassé les coûts et les délais initialement prévus, et propose moins de fonctionnalités et de fonctions que ce qui avait été demandé initialement.
- Echec du projet (« impaired project ») : le projet a été arrêté pendant son cycle de développement.
L’une des principales causes des dépassements de coûts et de temps est le redémarrage de projets. Sur 100 projets qui sont initiés, 94 sont des redémarrages, dont certains en sont à leur énième tentative.
Côté dépassement des coûts, voici le constat en chiffres (2015 – mais peu d’évolution depuis):
Et voici ceux des dépassements de délais :
Pour finir, voici les statistiques des échecs liés à la non-conformité des fonctionnalités et fonctions livrées en regard des attentes initiales :
L’aspect le plus important de la recherche du Standish Group a été d’identifier les causes des échecs de ces projets IT.
Pour ce faire, The Standish Group a sondé les cadres supérieurs des départements informatiques, afin de collecter leur opinion sur les raisons de la réussite des projets.
Les trois principales raisons de la réussite d’un projet sont la participation des utilisateurs, le soutien de la direction et un énoncé clair des besoins. Il y a d’autres critères de succès, mais lorsque ces trois critères sont respectés, les chances de réussite sont beaucoup plus grandes. Sans eux, le risque d’échec augmente de façon spectaculaire :
Les cadres sollicités dans le cadre de cette étude ont aussi été interrogés sur les facteurs conduisant leurs projets à être en difficulté (catégorie 2 de l’étude). Voici leurs réponses :
Enfin, la même question a été posée, cette fois-ci pour expliquer les raisons des annulations ou des reports de projets (3ème catégorie de l’étude) :
Ainsi, en tête des raisons expliquant les difficultés d’un projet, son échec ou son annulation, on retrouve des spécifications incomplètes, non claires ou ambiguës, le manque d’implication des utilisateurs, ainsi que les changements apportés aux exigences métier et aux spécifications. En tant que Business Analysts, nous devons donc sérieusement prendre la mesure de notre responsabilité!
Une autre conclusion clé de l’enquête est qu’un pourcentage élevé des dirigeants croient qu’il y a plus d’échecs de projets aujourd’hui qu’il y a cinq ou dix ans, et ce, malgré le progrès technologique.
La cause racine est malheureusement connue même si elle ne figure étrangement pas dans les registres des risques des projets : l’échec des projets a une cause essentiellement politique.
Deux commentaires collectés sont édifiants pour illustrer cet écueil majeur : ceux de Jim, directeur informatique chez un équipementier médical, et de Kathy, une développeuse dans un centre de télécommunication.
Jim : « C’est très difficile de piloter un projet quand les différents managers ont tous envie d’imposer leurs règles. Dans certains cas, vous devez les convaincre que la solution que vous préconisez est la meilleure pour l’entreprise, même si cela n’est pas forcément le meilleur choix pour eux à titre individuel. Si vous n’arrivez pas à avoir leur adhésion, vous savez que le projet va échouer. Peu importe que le projet soit gros ou pas. »
Kathy : « Parfois, on t’oblige à accepter une décision que tu n’aimes pas. Parfois même, cela va même à l’encontre de ta propre éthique. Tu le cries haut et fort, mais finalement, tu acceptes d’appliquer cette décision. C’est comme de se prendre un coup de marteau sur les orteils, ça fait mal. »
Le Standish Group conclut avec un brin de pessimisme que l’étude n’est cependant pas assez approfondie pour apporter une véritable solution à un problème aussi décourageant et récurrent que le taux d’échec des projets IT.
Pour mettre toutes les chances de leur côté, les chefs de projet et responsables informatiques doivent comprendre et analyser les défaillances qu’ils ont rencontrées. Cela s’appelle le retour d’expérience.
Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!
