brand

vous nÊTES PAS la cause d’un échec d’un projet informatique

vous nÊTES PAS la cause d’un échec d’un projet informatique

Je n’ai jamais eu de projet que j’ai personnellement échoué de 1969 à aujourd’hui. Le taux d’échec moyen des nouveaux projets est de 14% selon le magazine CIO.

L’article a couvert la plupart des choses qui peuvent être faites pour éviter l’échec. Cependant, ils ont raté une cause majeure d’échec. J’ai été témoin de trois projets, tous les 15 ans d’intervalle, qui ont échoué pour la même cause – une décision de gestion informatique. Un projet ne peut avoir qu’un seul objectif principal. Ils ont changé l’objectif du projet, passant de la résolution d’un problème commercial à la mise en œuvre de leur propre solution technique ou méthodologique préférée. Les coûts étaient énormes. Deux pourraient en fait être mesurés.

Il s’agissait de petits projets, à peine perceptibles, mais avec un impact important. Les trois projets ont commencé par coder une démonstration de faisabilité et une démonstration de l’utilisateur avec des données en direct. Du temps a été inclus dans le plan pour les ajustements en fonction des commentaires des utilisateurs et de l’achèvement du projet final à partir de la preuve de concept. La direction est intervenue après la démo et les a transférés à une autre équipe avec des instructions pour réécrire l’application. Les trois projets auraient pu être récupérés s’ils avaient juste discuté des leçons apprises avec l’équipe précédente, comme le souligne le point 7 de mon article «Innovation et turbulences» (Demandez de l’aide ou des conseils. Demandez à un expert s’il y en a un.).

Méthodologie de codage (la plus récente)

L’objectif principal de l’équipe était d’ajouter de la sécurité au prototype et de présenter l’application lors d’une convention. La structure de base avec laquelle ils ont commencé a parfaitement fonctionné (une entreprise a déclaré que cela ne pouvait pas être fait du tout). L’équipe s’est constamment disputée sur la façon dont elle était écrite, n’a pas pu respecter la date limite de la convention et a quitté sans écrire le module de sécurité. Le module de sécurité lui-même aurait été un succès partiel et aurait pu être écrit comme ils le voulaient. L’application avait le potentiel d’économiser plusieurs millions de dollars en recherche médicale, mais n’a jamais été commercialisée.

Plateforme (il y a 15 ans)

L’application a en fait été réécrite sans regarder le prototype et mise en production. Notre entreprise comptait 700 consultants sur le site du client. Le dépassement des coûts était si important et la date de mise en œuvre a été si manquée que le vice-président client a été réprimandé dans son examen par le président pour ne pas l’avoir tué tôt. Après cela, le client, par contrat, a réduit le nombre maximum de consultants sur site (70) chaque année ET le cabinet de conseil n’a plus reçu de nouveau projet. Un directeur de cabinet de conseil pensait que l’application était un succès dans la démonstration d’une technologie orientée objet.

Langage informatique (il y a 30 ans)

La nouvelle équipe n’a pas du tout pu terminer le projet. Je l’aurais eu dans User Acceptance Test dans les 2 semaines suivant la démonstration, mais la direction voulait qu’il soit converti en PL / 1, la langue qu’ils comprenaient. L’application a été demandée par le plus grand client extérieur de la division, le plus grand détaillant de batteries de voiture des États-Unis à l’époque. Un an plus tard, l’entreprise a perdu ce contrat de batterie.

Commentaires par inadvertance

Ce n’était pas un projet, mais il est lié. La machine qui convertissait le charbon en poudre en granulés fuyait de la poussière. Le vice-président principal visitait notre usine. Il a dit: «Serrez ces sceaux.» La machine a broyé les joints dans les granulés. Nous avons dû abandonner 12 millions de dollars de produits. Heureusement, notre base de données a pu isoler par numéro de lot le produit produit par cette ligne de production des 5 autres lignes. Cette déclaration a coûté 12 millions de bénéfices à la société cette année-là.

Aucun des gestionnaires impliqués dans les exemples n’a jamais su combien de dommages ils ont causés à leur entreprise ou à leurs clients. Il est très facile de détruire un projet en répétant l’histoire. Ne confondez pas les résultats du projet avec les résultats commerciaux. Faites toujours attention à ce que vous dites, faites attention aux petits projets et n’oubliez jamais l’objectif commercial.

Post Comment