Un tsunami de catastrophes de projets informatiques se profile à l'horizon

Ce n'est jamais la position populaire à prendre dans l'organisation d'être le pronostiqueur d'un désastre et d'un échec, donc j'écris cette missive avec la pleine compréhension que le contenu tombera dans l'oreille d'un sourd et que les avantages potentiels de mes conseils seront trouvés sur la pile de "J'aimerais que nous ayons…." Il y a un tsunami de projets catastrophiques qui se déplacent rapidement vers le rivage de l'entreprise et il n'y a pas grand-chose à faire pour l'arrêter.

Le type de catastrophes de projets dont je parle ne sont pas celles qui dépassent le budget et les délais, mais plutôt les échecs spectaculaires qui perturbent les chaînes d'approvisionnement, retardent la communication des informations financières et font exploser la carrière de cadres apparemment compétents. Ce sont les types d'échecs qui sont créés lorsque les entreprises « mettent en service » une mise en œuvre qui, avec le recul, sera considérée comme effectuée de manière imprudente.

4 signes avant-coureurs de malheur

Pourquoi suis-je si convaincu que de nombreux projets sont sur une trajectoire de collision avec l'échec ? Considérez ce qui suit :

• Doublez le volume. Il y a deux fois plus de grands projets en vol dont la mise en service est prévue entre mai et septembre de cette année par rapport à une année normale. Lorsque COVID a fermé ses portes au début de 2020, de nombreuses entreprises ont suspendu leurs grands programmes de transformation basés sur l'informatique. Au début de 2021, le barrage s'est rompu et de grands programmes qui devaient commencer en 2020 ont été lancés en 2021. Dans le même temps, les entreprises qui avaient initialement prévu de lancer des programmes en 2021 l'ont fait. Voila ! Cela signifie doubler le nombre de catastrophes potentielles du projet. Avec des délais de livraison de déploiement initiaux en moyenne de 12 à 18 mois pour les initiatives majeures, la table a été mise.

• Biais de récence. À quand remonte la dernière fois que vous avez entendu parler d'un échec de mise en service d'un projet majeur ? Des projets comme Select ComfortNational GridCover Oregonou Los Angeles Department of Water and Power (LADWP) sont passés sous silence depuis quelques années— assez longtemps pour qu'ils s'effacent de la mémoire de la suite C. L'orgueil organisationnel est une force puissante qui contrebalance souvent la réalité de la possibilité réelle de catastrophes. Lorsqu'il n'y a pas de nouvelles de catastrophes, la menace potentielle s'estompe. Il y a une raison pour laquelle nous conduisons tous plus prudemment après avoir vu un accident de voiture.
• Talents vides. Presque toutes les catastrophes majeures de mise en service peuvent être attribuées à un manque d'expérience de la part des membres seniors de l'équipe de projet. La capacité de déterminer et de communiquer les risques est évidemment primordiale pour les atténuer. Avec le double du nombre de projets en jeu, la capacité des intégrateurs de systèmes (IS) à apporter des talents hautement qualifiés à tous les programmes a été considérablement réduite. Ajoutez à cela les "grandes démissions" et les taux d'attrition qui ont doublé au cours des 6 derniers mois, et vous verrez que le niveau de conscience de la situation sur ces programmes a été considérablement réduit.
• Méthodes non testées. Nous avons vu de nombreux projets éprouver des difficultés dans les domaines des tests de systèmes intégrés pendant la pandémie. La source de l'impact sur la productivité est souvent attribuée au manque de colocation des équipes de projet. Sans être ensemble, les membres de l'équipe ne sont pas aussi rapides à apprendre de leurs voisins et les trucs et astuces ne sont pas transmis aussi facilement. Maintenant, avancez rapidement après le déploiement et tenez compte de l'impact potentiel sur des milliers d'utilisateurs qui pourraient ne pas avoir les super utilisateurs dans la chaise suivante pour les guider tout au long du démarrage. Il n'y a aucune raison de croire que les mêmes problèmes rencontrés lors des tests seraient miraculeusement résolus après le déploiement.

Comment éviter les catastrophes informatiques

Existe-t-il des moyens d'éviter le tsunami de catastrophes ? La réponse globale est malheureusement non. Les dés sont jetés. Existe-t-il des tactiques qui peuvent être mises en œuvre sur des programmes individuels pour prévenir une catastrophe ? Heureusement, cette réponse est oui. Voici quelques recommandations simples :

• Faites-en une réalité. Demandez à votre SI de préparer une présentation sur les leçons tirées des catastrophes majeures du programme. Vous n'avez pas besoin d'être le « messager qui se fait tirer dessus sur la plage ». Présentez cette présentation au comité directeur le plus tôt possible pour démontrer que vous prenez les mesures appropriées pour protéger l'entreprise.

• Établissez tôt les critères de mise en service. Trop de programmes constituent les critères d'entrée 2 à 3 mois avant la mise en service ciblée. Lorsque c'est le cas, le critère devient alors « Que pouvons-nous réaliser avant la mise en service » plutôt que « Où devrions-nous être ? » Cela est particulièrement vrai pour les projets soumis à des contraintes budgétaires.

• Vue indépendante. « Go-live » ou « fièvre du sommet » est réel – il suffit de demander à l'une des familles de ceux qui périssent en essayant d'atteindre le sommet d'une montagne. Un bon jugement est facilement obscurci par des évaluations de coûts irrécupérables et une planification injustifiée des meilleurs scénarios. Un point de vue indépendant peut donner à réfléchir.

Je me rends compte que ce message est probablement un peu déprimant ou qu'il peut être perçu comme un simple sensationnalisme, mais s'il met les roues en mouvement pour un seul projet afin d'éviter un désastre, c'était valoir la peine!