Retour d’expert Compass : les principales causes d’échec des projets IT

La politique de communication sur les projets

La plupart du temps, pour les projets réussis, l’entreprise ou la DSI communique sur les résultats flatteurs mais elle les explicite rarement. Pas d’analyse fine des facteurs de réussite, des bonnes pratiques, etc. C’est pourtant un travail naturellement faisable et ce, à moindre coût, dès lors que les processus sont standardisés, les méthodes et les outils de mesure mis en place, les indicateurs de pilotage définis et calculés. Ces analyses devraient figurer dans les bilans de projet ou les bilans annuels applicatifs et être réutilisés pour boucler la boucle d’un cercle vertueux du cycle de vie projet ou applicative. Rien de tout cela ne voit le jour une fois le projet terminé, ou très rarement.

Quant aux projets abandonnés ou ceux qui ont abouti mais affichent des facteurs de dépassement hors de l’entendement, la communication n’existe plus. Les éventuelles analyses de risque initiales sont oubliées, et l’analyse indispensable et honnête des causes de l’échec ne voit jamais le jour.

Philippe Prunet – « Nous avons là une première cause majeure endogène et purement politique : la décision de ne pas analyser (cela coûte encore un peu plus que l’échec) et de ne pas communiquer. Il arrive parfois que les résultats soient en quelque sorte ‘bricolés’ pour que l’inacceptable devienne un tant soit peu acceptable. Dans ce cadre, aucune leçon n’est tirée pour améliorer l’organisation, l’urbanisation, les choix technologiques, les méthodes de suivi et de pilotage des projets. »

Des estimations involontairement ou volontairement fausses

Les résultats statistiques de l’étude américaine sur les coûts, les charges et les délais, démontrent surtout des écarts entre un estimé et un constaté. En effet, la vraie question est celle de l’estimation. Les études et benchmarks AD/AM de Compass ont souvent démontré que les coûts et délais réels des projets (aussi bien en mode projet qu’en maintenance applicative) ne sont pas aussi catastrophiques que ces résultats le laissent entendre.

Philippe Prunet – « Nous avons là une deuxième cause importante liée aux estimations et à leurs méthodes ou outils. Les méthodes utilisées sont, pour la plupart de nos clients, des méthodes d’estimation dépassées basées sur des notions d’unités d’œuvre (donc orientées solutions techniques), réadaptées (même ‘bricolées’) localement, avec une incapacité notoire à estimer le moment où la décision budgétaire est cruciale, c’est-à-dire après une expression de besoin digne de ce nom. À ce propos, les expressions de besoin sont souvent incomplètes ou imprécises, d’où une impossibilité de définir le périmètre fonctionnel de l’application à réaliser. »

Lors d’une étude ou d’un audit des processus d’estimation et du contenu des composants et résultats de ces estimations, le constat est que le dénombrement, d’écrans, d’états, de fichiers interfaces y figure dans le meilleur des cas. Pour autant, une estimation n’est pas une valeur simple découlant de ce que l’on sait une fois que les phases de spécifications détaillées ou techniques sont déroulées et que les unités d’œuvre sont connues, mais bien une valeur composite intégrant notamment la couverture ou richesse fonctionnelle partant de l’expression de besoin, car c’est à ce moment que le ‘go, no go’ se décide.

Lorsque cette richesse fonctionnelle est évaluée initialement (au démarrage du projet) et réévaluée à deux ou trois instants clés du cycle de vie du projet, il est facile de démontrer une éventuelle dérive de périmètre fonctionnel et de justifier un décalage de coût par un argument précis (l’instabilité fonctionnelle) qui se distingue d’autres qui peuvent être tout aussi valables (comme les causes techniques, architecturales ou organisationnelles), mais qui ne sont pas toujours recevables de la part de la maîtrise d’ouvrage ou des utilisateurs. C’est une évidence : l’utilisateur ou la maîtrise d’ouvrage se reconnaît pleinement dans une évaluation basée sur une description fonctionnelle, et beaucoup moins lorsqu’on lui parle composants techniques.

Par ailleurs, les estimations initiales sont trop souvent sous-évaluées. L’estimation n’est plus involontairement fausse mais bien volontairement fausse. Et c’est plus grave. La raison majeure est que les entreprises raisonnent plus par budget à allouer que par nécessité métier ou valeur réellement ajoutée à l’entreprise. Mieux vaut un projet inutile à petit budget qu’un projet utile à gros budget. La seconde raison implique le sous-traitant (quand il y a outsourcing ou offshoring). Celui-ci, pour emporter le marché face à la concurrence, proposera le budget le plus serré possible (dans le contrat initial) quitte à se rattraper sur des avenants, ce qui sera le cas systématiquement dès lors que le projet (en mode « design to cost ») ne correspond pas pleinement au besoin initial. On a fait a minima et on en aura pour le maxima.