Pourquoi les projets informatiques échouent toujours

En effet, les chefs de projet 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 plusieurs projets, explique-t-il. Ils sont également plus capables de mettre en œuvre la gouvernance nécessaire pour maintenir les projets sur la bonne voie afin de fournir ce qui est attendu et de ne pas laisser la portée augmenter les coûts et les calendriers sans ajouter de valeur supplémentaire.

2. Peu ou pas de soutien de la direction

Autre problème de leadership qui peut faire échouer un projet informatique : l’indifférence au plus haut niveau.

Ce scénario se produit plus qu’il ne le devrait, affirment les chefs de projet chevronnés.

« Nous avons eu des réunions et des rapports sur l’état d’avancement des projets au cours desquels les dirigeants se demandaient : « Pourquoi faisons-nous cela ? Ils n’ont vraiment pas compris l’importance de l’endroit où nous allions », déclare Karla Eidem, professionnelle en gestion de projet et responsable des opérations régionales de PMI pour l’Amérique du Nord.

Eidem affirme qu’un manque de soutien de la direction peut survenir même lorsque le projet est sponsorisé par une unité commerciale – une situation qui indique que le projet, bien qu’il s’agisse peut-être d’une priorité localisée, n’est pas aligné sur les objectifs de l’organisation.

Dans de tels cas, il est nécessaire de réaligner.

« Cela peut impliquer de demander au [executive team]: Compte tenu de tous les faits qui vous sont présentés, ce projet est-il une réussite ou non ? Parfois, c’est interdit pour une raison quelconque, mais cette décision doit être prise », explique Eidem, expliquant que le soutien de la direction est crucial pour le succès car il garantit que les ressources (argent, pouvoir des personnes, attention, etc.) seront utilisées. être mis à disposition.

De même, libérer le sponsor commercial du projet de toute responsabilité quant au succès du projet technologique – et confier tout cela à l’informatique – peut condamner le projet.

« Il faut vraiment avoir un bon leadership de projet, et cela commence par que la personne qui a rédigé l’analyse de rentabilité soit le sponsor, s’assure que le projet est réalisé de manière réaliste et soit un champion », explique Wu..

Les sponsors commerciaux, tout comme les dirigeants, jouent un rôle important en expliquant les raisons commerciales du projet, en établissant les bénéfices attendus et en mobilisant les ressources vers la cause. Leur soutien signale également au personnel l’importance du projet, qui contribue à favoriser l’adoption de nouvelles technologies et tout changement de processus associé, ajoute Wu..

Un sponsor commercial solidaire et informé peut éliminer les obstacles et les goulots d’étranglement qui surviennent, il peut aggraver les problèmes pour aider à les résoudre rapidement, et il peut défendre les réussites pour créer une dynamique et un enthousiasme pour les changements à venir, explique Eidem.

Ces avantages disparaissent lorsqu’un sponsor commercial est MIA.

Eidem a vu cela se produire.

Elle travaillait sur la mise en œuvre d’un logiciel multisite complexe qui progressait régulièrement jusqu’à ce qu’elle ait besoin de ce sponsor commercial pour rassembler les divisions régionales pour la prochaine étape du processus. Le sponsor a laissé tomber la balle, laissant certaines équipes opérationnelles dans le flou sur ce qui se passait et d’autres se demandant pourquoi elles devaient participer.

« Nous avons constaté que les informations ne se répercutaient pas en cascade et qu’il y avait une certaine résistance dans certains domaines », explique Eidem, ajoutant que la situation mettait en péril la dynamique du projet.

Eidem dit avoir découvert que l’entreprise sponsor avait été éloignée du projet en raison d’un autre problème majeur et que, par conséquent, elle n’était pas aussi attentive que nécessaire dans la transmission des informations sur le projet aux régions concernées.

« J’avais besoin que le sponsor se concentre sur ce projet, mais il avait trop d’autres priorités. Je devais donc être claire : en tant qu’organisation, nous avons dit que ce projet était la priorité n°1 », dit-elle.

Pour éviter l’effondrement du projet, Eidem a programmé davantage de réunions individuelles avec le sponsor afin de construire une relation plus solide et de permettre une communication plus directe sur les besoins du projet, ce qui a permis de recentrer le sponsor et de relancer le projet.

5. Ne pas impliquer toutes les parties prenantes

Krista Phillips, chef de projet informatique, raconte un cas dans lequel une grande société multinationale a mis en œuvre une nouvelle technologie dans l’ensemble de ses entreprises, mais a surpris une division complètement ignorante du travail de mise en œuvre en cours.

Il s’avère que cette division spécifique a été exclue de tous les processus de planification et de projet.

«Je ne sais pas comment le [project leaders] ils ont raté ça, mais ils ont raté une unité entière. Alors, quand le système a été mis en ligne, ils se sont demandé : « Qu’est-ce que c’est ? Cela a fait que l’équipe du projet a manqué de portée », explique Phillips, titulaire d’un PMP et président de la section régionale de Pikes Peak de PMI au Colorado.

Phillips reconnaît que les équipes de projet ne négligent généralement pas des divisions entières, mais elles ne parviennent parfois pas à identifier et à inclure toutes les parties prenantes qu’elles devraient participer au processus de projet. Par conséquent, ils manquent d’exigences clés à inclure, de réglementations à prendre en compte et d’opportunités sur lesquelles capitaliser.

6. Pas assez de ressources ou pas les bonnes

Certains chefs de projet citent l’attente dominante de faire plus avec moins comme une autre raison de l’échec des projets informatiques actuels. Ils affirment que cette mentalité conduit généralement les équipes de projet à manquer des ressources dont elles ont besoin pour accomplir le travail souhaité à temps.

« Tout le monde est très préoccupé par ce résultat financier, et ils devraient s’en préoccuper, mais l’autre aspect est qu’ils s’attendent à ce que quelques personnes fassent beaucoup de choses », dit Phillips.

Par exemple, elle dit que les travailleurs sont fréquemment affectés à plusieurs projets simultanément, et que beaucoup sont affectés à ce projet en plus de leurs tâches existantes. En conséquence, ces travailleurs sont tiraillés dans trop de directions différentes.

D’autres affirment que les dirigeants d’entreprise sous-estiment les coûts et le temps nécessaire pour terminer le travail ou qu’ils ne parviennent pas à allouer les bons talents à l’équipe (pensant que des travailleurs non formés ou inexpérimentés développeront les compétences requises sur le tas), alors même que les chefs de projet font ressortir les conséquences d’une sous-estimation. -allouer l’argent, le talent et le temps nécessaires au succès.

Les chefs de projet expérimentés affirment qu’il est crucial que les chefs de projet informatiques et les DSI eux-mêmes veillent à ce que les sponsors commerciaux et les cadres supérieurs obtiennent les informations dont ils ont besoin pour être réalistes quant aux ressources, au support et aux calendriers requis.

Mais les chefs de projet reconnaissent également qu’il s’agit d’une tâche toujours difficile.

Pour aider, ils conseillent de mettre en œuvre un programme de gestion de portefeuille pour apporter une visibilité sur tout le travail en cours et pour briser les silos de projets qui peuvent parfois contribuer à cette sous-allocation des ressources.

« Mettre l’accent sur la gestion de portefeuille peut éliminer une grande partie des problèmes de productivité », explique Wu. « Faites aussi moins de choses et faites-les bien ; c’est une caractéristique de la gestion de portefeuille.

7. Manque de collaboration en personne

Wu reconnaît les avantages apportés par le passage au travail à distance à grande échelle, tels que la possibilité d’étendre le travail de projet à l’échelle mondiale. Mais il voit également comment l’environnement de travail virtuel peut créer des problèmes dans la réalisation des projets.

Pour commencer, Wu 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 d’aborder les tâches des modules, le virtuel est une bonne chose. Mais pour résoudre des problèmes importants et complexes, vous ne pouvez pas faire grand-chose avec Zoom », dit-il.

Wu dit qu’il constate également que certaines équipes ont du mal à créer des liens dans des environnements de travail virtuels. « Vous sacrifiez la connexion humaine », ajoute-t-il.

Par conséquent, Wu affirme que le travail peut prendre plus de temps ; résoudre un problème qui prendrait une heure en travaillant ensemble face à face pourrait prendre 90 minutes dans un environnement virtuel. Et les transferts qui se déroulaient rapidement et sans problème lorsque les équipes étaient physiquement côte à côte nécessitent désormais souvent plus de temps pour se coordonner sur les écrans d’ordinateur.

« Les gens passent plus de temps pour atteindre la même efficacité nette, et je pense que les relations humaines commencent à s’effilocher », dit-il, soulignant que les nouveaux employés en particulier risquent de ne pas bénéficier du mentorat informel et de l’apprentissage qui se produisent en personne lorsqu’ils travaillent. peut facilement voir de bons modèles et de bons modèles de travail à imiter.

Wu dit que ces dynamiques imposent à leur tour plus de travail aux chefs de projet qui doivent « consacrer beaucoup plus de travail et de temps pour collaborer et communiquer », ajoutant qu’il n’a pas encore vu de solutions à ces défis. « Je connais le problème, mais je n’ai pas de solution », dit-il.

8. Transferts décousus

À un moment donné, un projet passe en production, les chefs de projet s’en vont et l’initiative informatique est alors censée montrer sa valeur.

Ces mesures dans de nombreuses organisations signifient que les projets – et tous les problèmes qui subsistent – ​​sont toujours rejetés par-dessus la clôture, ce qui conduit à une responsabilisation incohérente qui ne mène pas au succès, explique Wu.

« Si l’analyse de rentabilisation est une partie, et que le chef de projet est une autre partie, et que les personnes qui gèrent les résultats du projet, qui sont encore plus éloignées de l’analyse de rentabilisation du projet, sont une autre partie, alors vous pouvez voir les disparités entre les deux parties. connexions », dit Wu.

Cette incohérence peut signifier des opportunités manquées, des mauvais virages et des problèmes de communication qui conduisent à des produits finaux sous-optimaux.

Wu affirme que des disparités peuvent survenir même dans les organisations utilisant les méthodologies Agile et DevOps, affirmant que celles-ci « ne sont que des façons différentes de transporter l’eau d’un côté à l’autre ».

Il ajoute : « Le DevOps peut répondre à un changement très rapidement, mais savoir si ce changement est le bon changement ou s’il génère un retour sur investissement est une question très différente. »

Pour contrecarrer cela, Wu et d’autres soulignent la nécessité d’une bonne gestion et d’une gouvernance de projet solide qui relie continuellement l’analyse de rentabilisation du projet à ses livrables tout au long du travail du projet ainsi que pendant les phases de mise en œuvre et d’adoption.