Compass Management Consulting Les 4 causes fondamentales de l’échec des projets IT

jeudi 22 décembre 2011

Politique de communication sur les projets,  des estimations involontairement ou volontairement fausses, la complexité législative et réglementaire et l’historique des Systèmes d’Information des entreprises, telles sont les quatre principales causes de l’échec  des projets informatiques. C’est l’explication que propose Compass Management Consulting , une filiale du groupe Information Services Group(ISG).

Une étude menée il y a quelques années aux Etats-Unis par Standish Group auquel il fait souvent référence, donne les résultats suivants :
- 31% des projets ne seront jamais terminés,
- Plus de 52% des projets auront un coût représentant 189% de l’estimation initiale,
- Uniquement 16% des projets se termineront dans les budgets et les délais initiaux ; ce chiffre tombe à 9% pour les grandes entreprises,
- Le délai moyen de dépassement des projets est de 230%,
- Sur 100 projets lancés, 94% devront être relancés.

« Certes, cette étude est américaine et pour des projets américains,  constatePhilippe Prunet. Consultant de Compass Management Consulting. Je ne crois pas qu’une telle étude ait déjà été menée en France, même s’il existe ici ou là dans divers rapports ou analyses plus ou moins confidentiels des ordres de grandeur approchant. On peut raisonnablement penser que ces constats soient les mêmes en France ».

Ce type d’analyse est par définition difficile à mettre en œuvre, notamment dans les grandes entreprises, car la plupart des projets « ratés » sont cachés, non révélés officiellement, politiquement incorrects et donc non mesurables.  Parmi les causes très souvent évoquées : le management, la gestion des projets, l’organisation, la sous-traitance, l’outsourcing, la technologie en complexité croissante, l’expression de besoin mal définie, les choix d’architecture ou de progiciels mal adaptés sont certainement fondées … Mais selon Compass Management Consulting,  il existe des raisons beaucoup plus puissantesen termes d’impact négatif sur le bon déroulement des projets et le bon fonctionnement des Systèmes d’Information. Elles ont la particularité d’être plutôt invisibles mais avec un effet de levier considérable sur les causes apparentes et visibles citées précédemment. ».

1.       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.

C’est 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.

2.       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.
« Nous avons souvent démontré dans nos études et nos benchmarks AD/AM 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 »poursuit Philippe Prunet.

Il s’agit là d’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. A ce propos, les expressions de besoin sont souvent incomplètes ou imprécises, d’oùuneimpossibilitéde définir le périmètre fonctionnel de l’application à réaliser.

 « Lorsque nous sommes amenés à étudier ou auditer les processus d’estimation et le 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, poursuit le consultant. 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 à 2 ou 3 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.

3.       La complexité législative et réglementaire

Un autre aspect, rarement évoqué dans les points de vue que l’on peut voir sur internet ou dans la presse spécialisée, est relatif à la complexité réelle ou supposée des systèmes d’informations. Concernant les SI des grandes entreprises (celles du CAC 40 ou assimilées), cette complexité revêt plusieurs axes : l’architecture fonctionnelle et technique du SI, l’organisation des projets, la législation (les lois et règlements internes ou externes), la sécurité, l’externalisation et bien d’autres. Il existe ici un domaine dont on ne parle quasiment jamais, mais qui à lui seul peut faire monter la note de 2 à 3 fois sa valeur initiale possible : la législation au sens large.

C’est troisième cause majeure est liée à la complexité législative et réglementaire. En effet, l’impact est souvent fonctionnellement considérable (et c’est une spécificité française) sur les Systèmes d’Informations (SI) de l’entreprise comme le SI RH (gestion des ressources humaines de l’entreprise qui intègre la Paie), le SI Comptable ou d’autres comme la Facturation.

Le point commun de ces systèmes est qu’ils sont transverses à toutes entreprises, soumis à des lois et règlements, à des conventions collectives générales et particulières, bref à une panoplie (dont nous avons en France probablement le record du monde) de règles qu’il faut impérativement implémenter dans ces systèmes. Etrangement, On constate que les fameux projets de développement ou les maintenances applicatives qui coûtent deux à trois fois plus cher que prévu (en oubliant que l’estimation initiale peut être en cause) se situent majoritairement dans ces SI transversaux (RH, Finances, Paie, Comptabilité, …). On ne rencontre pas de tels ratios pour les SI « cœur de métier ».

Cela constitue assurément une richesse fonctionnelle (à comparer à des systèmes équivalents dans d’autres pays d’Europe ou du monde) mais cela induit aussi une architecture fonctionnelle et technique complexe.

Ces SI intègrent, pour la plupart, une grande quantité de progiciels (parfois 4 ou 5 pour un même SI). Les éditeurs ont misé beaucoup en terme de couverture fonctionnelle et de souplesse de paramétrage, mais jamais assez pour telle ou telle grande entreprise française. A priori, l’idée d’opter pour un progiciel peut sembler évidente dans ces cas : la législation est la même pour tout le monde.

Chaque SI devrait être quasiment identique et « progicialisé » au maximum et, d’une entreprise à l’autre, les différences devraient être mineures. Pourtant, ce n’est pas le cas. Chaque DSI produit sa solution. Sur ces SI, les progiciels sont souvent utilisés de manière peu standard, avec des coûts d’adaptation ou des développements spécifiques explosifs.

4.       L’historique des Systèmes d’Information des entreprises

L’informatique au sens n’a cessé de se développer de manière exponentielle en outils et en performance depuis 40 ans.  Pour répondre à un même besoin utilisateur, de nombreux scenarii sont possibles aujourd’hui, en termes d’architectures techniques, de choix d’outils ou de progiciels. Il existe moult façons d’apporter la solution informatique à une demande fonctionnelle de maîtrise d’ouvrage. Tous ces scenarios sont-ils bien envisagés du point de vue du risque, de l’efficience, de la performance, des coûts ? Pas si sûr.

Une chose est certaine : la nouvelle application dont on rêve et qui aurait tous ces indicateurs au vert doit s’insérer dans un SI entreprise existant et cohabiter avec de multiples applications plus ou moins anciennes (parfois très anciennes, plus de 20 ans), plus ou moins complexes, plus ou moins bien architecturées, avec des données plus ou moins bien urbanisées, etc. Et c’est ainsi que la complexité fonctionnelle et technique peut devenir elle aussi explosive avec les coûts de fabrication et de maintenance qui en découlent.

« N’oublions pas que les coûts de refonte des SI sont souvent très élevés, précisément dus au fait d’une intégration complexe, avec une valeur ajoutée quasi nulle lorsqu’il s’agit de refaire « en plus moderne » une application à iso-fonctionnalité. Heureusement, la nouvelle application « plus moderne » sera plus séduisante, plus attractive pour l’utilisateur. Sera-t-elle plus performante ? Rendra-t-elle un service supérieur pour l’utilisateur dans le cadre de ses tâches quotidiennes ? A méditer »,conclut Philippe Prunet.

Source: infoDSI.com

 

http://www.infodsi.com/articles/126866/compass-management-consulting-4-causes-fondamentales-echec-projets-it.html?key=