Les DSI ont travaillé dur pour mettre derrière elles les problèmes qui, des décennies durant, ont affecté leurs anciens processus de livraison de projets. Elles ont tiré un trait sur les projets trop ambitieux, la méthodologie en V et les délais à rallonge par le développement itératif, l'approche agile et les sprints de plusieurs semaines, dans l'espoir d'éviter les échecs majeurs qui ont émaillé l'histoire des technologies de l'information.

Ces changements ont en effet été bénéfiques, mais de nombreux projets informatiques continuent d'échouer. Il est vrai que l'échec d'un projet n'entraîne plus aujourd'hui l'effondrement de l'ensemble de l'environnement informatique (encore que Birmingham soit récemment un contre-exemple), comme cela aurait pu être le cas par le passé. Il ne signifie pas non plus que le nouveau système ne fonctionne pas du tout et qu'il doit être complètement abandonné, un autre scénario classique de l'histoire mouvementée de la livraison de projets IT.

Aujourd'hui, l'échec signifie plutôt qu'un projet informatique n'apporte pas tout ou partie des bénéfices escomptés. L'échec peut aussi signifier qu'un projet n'est pas rentable, qu'il est tellement en retard qu'il est devenu obsolète lorsqu'il est livré, ou qu'il fait fuir ses utilisateurs cibles. « Aujourd'hui, avec les progrès de l'agilité, la définition de l'échec a évolué », explique Te Wu, PDG et chef de projet de PMO Advisory, professeur associé à l'université d'État de Montclair et professionnel de la gestion de projet, qui est également coprésident de l'équipe de développement du Project Management Institute.

En d'autres termes, l'échec d'un projet informatique est aujourd'hui davantage lié à des étapes manquées qu'à des catastrophes technologiques. Certaines études le confirment. Selon l'enquête 2023 Technology Survey de KPMG, 51 % des 400 responsables technologiques américains ayant répondu à l'enquête ont déclaré n'avoir constaté aucune augmentation des performances ou de la rentabilité de leurs investissements dans la transformation numérique au cours des deux dernières années. Les enquêtes et les études ne sont pas concordantes sur le taux d'échec des projets informatiques, mais les chercheurs confirment que le pourcentage de projets informatiques qui n'aboutissent pas continue à être plus élevé qu'espéré. Pourquoi les projets informatiques continuent-ils d'échouer ? Dans la plupart de ces dérapages, on peut reconnaître quelques traits communs. Revue de détails.

1. Manque d'expertise en matière de gestion de projet

Les collaborateurs sont souvent sollicités pour effectuer des tâches supplémentaires et, pour les informaticiens, cela signifie parfois qu'ils sont chargés de diriger des projets. Mais ces derniers n'ont pas nécessairement l'expertise, la formation ou l'expérience nécessaires pour réussir dans ce rôle, et on ne leur donne pas assez de temps pour apprendre ce qu'il faut pour gérer un projet ou pour accomplir les tâches supplémentaires nécessaires à cet exercice.
« Nous attendons de personnes qui n'ont aucune formation en la matière qu'elles dirigent des projets. Ou bien nous attendons des responsables qui ont un emploi à plein temps dans un autre domaine qu'ils gèrent également un projet », observe Zach Rossmiller, directeur informatique de l'université du Montana. Un DSI qui connaît les conséquences de cette approche... car son service informatique a toujours procédé de la sorte ! « Nous avions deux cents projets différents en cours et nous attendions de nos responsables qu'ils les gèrent et qu'ils les gèrent efficacement, explique-t-il. Si nous avions eu un bureau de gestion de projet (PMO, Project Management Office) dédié au sujet, je pense que nous aurions été bien mieux lotis. »

Zach Rossmiller s'efforce de remédier à cette situation, via l'ajout récent de deux chefs de projet à son équipe informatique. Selon lui, l'arrivée de professionnels formés à la gestion de projets apporte déjà des améliorations, notamment en rationalisant les efforts et en rendant l'exécution des projets plus efficace. En effet, les chefs de projet dûment formés sont mieux à même de rassembler et de planifier les ressources, de coordonner les horaires du personnel et de faire avancer tout le monde dans la même direction - et ce, sur un périmètre comprenant plusieurs projets, explique le DSI. Ils sont également plus à même de mettre en oeuvre la gouvernance nécessaire pour que les projets restent dans la cible définie et produisent les résultats escomptés, évitant le piège de l'élargissement du champ d'application et ses conséquences en matière d'augmentation des coûts et des délais.

2. Peu ou pas de soutien de la part de la direction

Un autre problème de leadership peut faire échouer un projet informatique : l'indifférence de l'échelon supérieur. Ce scénario se produit plus souvent qu'il ne le devrait, affirment des chefs de projet chevronnés. « Nous avons eu des réunions et des rapports sur l'état d'avancement du projet au cours desquels les dirigeants demandaient : 'Pourquoi faisons-nous cela ?' Ils ne saisissaient vraiment pas l'importance de ce que nous faisions », explique ainsi Karla Eidem, professionnelle en gestion de projet et responsable des opérations régionales du Project Management Institute pour l'Amérique du Nord.

Selon celle-ci, le manque de soutien de la direction peut survenir même lorsque le projet est parrainé par une unité opérationnelle, ce qui indique que le projet, même s'il s'agit peut-être d'une priorité locale, n'est pas aligné sur les objectifs de l'organisation. Dans ce cas, un réalignement s'avère absolument indispensable. « Cela peut signifier qu'il faut demander à [l'équipe de direction] : 'compte tenu de tous les faits qui vous sont présentés, ce projet est-il acceptable ou non ?' Parfois, c'est un non pour une raison ou une autre, mais cette question doit être clairement tranchée », explique Karla Eidem, qui précise que le soutien de la direction est essentiel à la réussite du projet, car il garantit que les ressources - argent, ressources humaines, attention, etc. - seront bien disponibles.

3. Absence de responsabilité du sponsor de l'entreprise

De même, le fait de décharger le sponsor du projet de la responsabilité de la réussite de l'initiative - et de tout mettre sur le dos de l'informatique - est une autre source d'échec. « Il est essentiel d'avoir une bonne direction de projet, et cela commence par la personne qui a rédigé l'analyse de rentabilité, qui en est le sponsor et qui s'assure que le projet est mené de manière réaliste », explique Te Wu, PDG et chef de projet de PMO Advisory. Les sponsors, comme les dirigeants, jouent un rôle important en exposant les raisons du projet, en établissant les avantages associés et en ralliant les ressources à la cause. Leur soutien signale également au personnel l'importance du projet, ce qui contribue à l'adoption des nouvelles technologies et aux changements de processus qui en découlent, relève Te Wu.

4. Manque d'engagement du sponsor de l'entreprise

Selon Karla Eidem, un sponsor métier bien informé et au soutien de l'initiative peut éliminer les obstacles et les goulets d'étranglement qui se présentent, il peut faire remonter les problèmes pour les résoudre rapidement et il peut se faire le porte-parole des réussites, pour créer un élan et un enthousiasme pour les changements qui s'annoncent. Ces avantages disparaissent lorsque le sponsor est absent. Et Karla Eidem en a été témoin, lorsqu'elle travaillait sur la mise en oeuvre d'un logiciel complexe pour plusieurs sites. Un projet qui progressait régulièrement jusqu'à ce qu'elle ait besoin d'un sponsor pour réunir les divisions régionales en vue de l'étape suivante. Le sponsor n'est alors pas intervenu, laissant certaines équipes opérationnelles dans l'ignorance de ce qui se passait et d'autres à se demander pourquoi elles devaient participer à cette réunion. « Nous avons constaté que les informations ne cascadaient pas et qu'il y avait une certaine résistance dans certains domaines », explique la responsable du Project Management Institute, ajoutant que cette situation mettait en péril la dynamique du projet.

Karla Eidem explique qu'elle a découvert que le sponsor de l'entreprise avait été éloigné du projet par un autre problème important et que, par conséquent, il n'était plus aussi attentif qu'il le fallait pour transmettre des informations aux régions concernées. « J'avais besoin que le sponsor se concentre sur ce projet, mais il avait trop d'autres priorités. J'ai donc dû être claire : en tant qu'organisation, nous avons affirmé que ce projet était la priorité numéro un », explique-t-elle. Pour éviter que le projet ne s'étiole, Karla Eidem a programmé davantage de réunions individuelles avec le sponsor afin d'établir une relation plus solide et assurer une communication plus directe sur les besoins du projet. Ce qui a permis de remobiliser le sponsor et de relancer le projet.

5. Ne pas impliquer toutes les parties prenantes

Krista Phillips, chef de projet informatique, raconte qu'une grande multinationale a mis en oeuvre une nouvelle technologie dans l'ensemble de ses filiales, mais qu'une division n'était pas du tout au courant des travaux en cours. Cette division avait été tenue à l'écart de tous les processus de planification du projet. « Je ne sais pas comment les chefs de projet ont pu l'oublier une unité entière. Mais lorsque le système a été mis en service, cette division s'est demandé de quoi il s'agissait. L'équipe de projet avait clairement commis une erreur dans la définition du périmètre », explique Krista Phillips, qui préside le chapitre régional du PMI dans le Colorado.

Certes, la plupart du temps, les équipes projets ne négligent pas des divisions entières, mais elles omettent parfois d'identifier et d'inclure toutes les parties prenantes dans le processus de planification. Par conséquent, elles manquent des exigences clés à inclure, des réglementations à prendre en compte et des opportunités à exploiter. Sans oublier l'impact en matière de gestion du changement, les 'oubliés' ayant logiquement tendance à renâcler quand la mise en oeuvre intervient.

6. Pas assez de ressources ou pas les bonnes

Certains chefs de projet citent l'exigence perpétuelle de 'faire plus avec moins' comme une autre raison de l'échec des projets informatiques. Selon eux, cette mentalité conduit généralement les équipes projets à ne pas disposer des ressources dont elles ont besoin pour réaliser le travail souhaité dans les délais impartis. « Tout le monde est très préoccupé par le résultat net, et c'est bien légitime, mais le revers de la médaille est que l'organisation attend de quelques personnes qu'elles fassent beaucoup de choses », explique Krista Phillips. Par exemple, elle explique que les collaborateurs sont souvent affectés à plusieurs projets simultanément, ou que nombre d'entre eux sont affectés à une initiative de transformation en plus de leurs tâches quotidiennes. Par conséquent, ils se voient sur-sollicités et tiraillés entre de multiples priorités.

D'autres spécialistes relèvent que les chefs d'entreprise sous-estiment les coûts et le temps nécessaire pour achever le travail ou qu'ils n'affectent pas les bonnes compétences à l'équipe (pensant que les collaborateurs non formés ou inexpérimentés développeront les compétences requises sur le tas). Et ce alors même que les chefs de projet font déjà face aux conséquences d'une sous-affectation de budget, de compétences ou à des délais trop tendus pour assurer la réussite du projet. Les chefs de projet IT et les DSI doivent donc tout particulièrement veiller à ce que les commanditaires et les décisionnaires reçoivent les informations nécessaires pour être réalistes en ce qui concerne les ressources, le support et le calendrier nécessaires à l'aboutissement d'une initiative.

Les chefs de projet que nous avons interrogés reconnaissent toutefois qu'il s'agit là d'une tâche difficile. Pour les aider, ils conseillent de mettre en oeuvre un programme de gestion de portefeuille afin d'avoir une visibilité sur l'ensemble des travaux en cours et de briser les cloisonnements entre les projets qui peuvent parfois contribuer à cette sous-affectation des ressources. « En mettant l'accent sur la gestion de portefeuille, il est possible d'éliminer une grande partie des problèmes de productivité », explique Te Wu. « Faire moins de choses, aussi, et les faire bien ; c'est la marque de fabrique d'une bonne gestion de portefeuille. »

7. Le manque de collaboration

Si Te Wu reconnaît les avantages du passage au télétravail à grande échelle - comme la possibilité de réunir des compétences à l'échelle mondiale -, il constate également que l'environnement de travail virtuel peut créer des difficultés dans la gestion des projets. Tout d'abord, il dit avoir constaté que les équipes virtuelles ont plus de mal à se réunir pour résoudre les problèmes les plus difficiles. « Je pense que lorsqu'il s'agit de s'attaquer à des tâches modulaires, le virtuel est une bonne chose. Mais pour résoudre des problèmes importants et complexes, il y a des limites à ce que l'on peut faire avec Zoom », explique-t-il. Et d'expliquer qu'il constate également que certaines équipes ont du mal à tisser des liens dans les environnements de travail virtuels.

En conséquence, Te Wu estime que cette organisation peut ralentir le rythme de certains projets ; la résolution d'un problème qui prendrait une heure en face à face peut prendre 90 minutes dans un environnement virtuel. De plus, les transferts qui se faisaient rapidement et sans heurts lorsque les équipes étaient physiquement côte à côte nécessitent souvent plus de temps pour se coordonner à travers les écrans d'ordinateur. « Les gens passent plus de temps à atteindre la même efficacité nette, et je pense que les relations humaines commencent à s'effriter », dit-il, notant que les nouveaux employés en particulier peuvent souffrir de l'absence de mentorat informel et d'apprentissage par l'exemple. Selon Te Wu, cette dynamique alourdit la charge de travail des chefs de projet, qui doivent « consacrer beaucoup plus de travail et de temps à la collaboration et à la communication », ajoutant qu'il n'a pas encore trouvé de réelle solution à ces problèmes.

8. Des transferts de responsabilités décousus

À un moment donné, un projet entre en production, les chefs de projet passent à autre chose et l'initiative informatique est alors censée montrer sa valeur. Dans de nombreuses organisations, cette étape signifie que les projets - et tous les problèmes qui subsistent - sont transférés abruptement d'une équipe à une autre, ce qui conduit à des interrogations sur les responsabilités de l'une ou l'autre et peut handicaper la réussite de l'initiative, affirme Te Wu. « Si l'analyse de rentabilité est gérée par une entité, que la chefferie de projet en est une autre et que les personnes qui prennent en charge les résultats du projet en sont une troisième, les jointures sont largement distendues », explique le spécialiste et professeur d'université.

Ce manque de cohérence peut se traduire par des opportunités manquées, des décisions erronées et des erreurs de communication qui aboutissent à des produits finaux non optimaux. Te Wu précise que ce manque de cohésion peut se produire même dans les organisations qui utilisent les méthodologies agile et DevOps, car ces dernières « ne sont que des façons différentes de transporter l'eau d'un côté à l'autre ». Donc ne résolvent rien quant à la fluidité des transferts de responsabilité. « Le DevOps peut aborder un changement très rapidement, mais savoir si ce changement est le bon ou s'il apporte un retour sur investissement est une question très différente », observe Te Wu. Pour contrer ces dérives, ce dernier et d'autres spécialistes soulignent la nécessité d'une gestion et d'une gouvernance de projet solides, faisant continuellement le lien entre l'analyse de rentabilité du projet et les livrables durant les développements ainsi que pendant les phases de mise en oeuvre et d'adoption.