Pourquoi les grands projets informatiques ont-ils tendance à échouer ou à avoir de gros dépassements de coûts / délais? [fermé]

J'ai toujours lu des informations sur les projets de transformation ou d'intégration à grande échelle qui sont un désastre total ou presque total. Même s'ils réussissent d'une manière ou d'une autre à réussir, le coût et l'échéancier prévu sont énormes. Quelle est la vraie raison derrière les grands projets étant plus enclins à l'échec. Peut-on utiliser agile dans ce genre de projets ou l'approche traditionnelle reste la meilleure.

Le projet Queensland Payroll, en Australie, où les critères de réussite des tests ont été modifiés pour réaliser le projet, en est un exemple.
Voir d'autres projets échoués dans cette question SO ( sur Wayback Machine )

Avez-vous une expérience personnelle à partager?

La raison principale est une augmentation de la portée , que le livre "The Pragmatic Programmer" décrit comme:

• ballons caractéristiques
• featurism rampant
• fluage des exigences

C'est un aspect du syndrome de la grenouille bouillie.

L’idée des différentes méthodes «agiles» est d’accélérer le retour d’information et, espérons-le, de corriger l’évolution du projet dans le temps.

Mais l’autre raison est la gestion des versions : si vous n’êtes pas prêt à publier le projet (aussi imparfait soit-il), il risque d’échouer (car publié trop tard, avec trop de fonctionnalités buggy et plus difficile à corriger / mettre à jour / améliorer).

Cela ne signifie pas que vous devez avoir une date de publication fixe, mais cela signifie que vous devez être capable de créer à tout moment une version en cours d'exécution de votre programme, afin de le tester / évaluer / le publier.

Le billet de blog " Les projets en retard sont en retard un jour à la fois " contient de nombreux autres exemples:

Je sais que la solution consiste à assouplir la portée et à garder la date de lancement fixe, mais cela ne fonctionne pas s'il existe une fonctionnalité convenue qui ne peut pas être complétée à temps.

C'est pourquoi nous ne préconisons pas les spécifications ou la «fonctionnalité convenue». C'est la racine du problème - dire que vous savez tout sur ce dont vous avez besoin et sur la façon dont il sera mis en œuvre avant même que le premier pixel ne soit peint ou qu'une ligne de code ne soit écrite. .

Lorsque vous prédisez un avenir rigide sur un cadeau flexible, vous avez des problèmes. Les avenirs rigides sont parmi les choses les plus dangereuses. Ils ne laissent pas de place à la découverte, à l'émergence et aux erreurs qui ouvrent de nouvelles portes.

Habituellement, la complexité du projet est sous - estimée .

Steve McConnell (de "Code Complete" renommée) a une liste des erreurs classiques .

Certaines pratiques de développement inefficaces ont été choisies si souvent, par tant de personnes, avec des résultats si prévisibles et si mauvais qu’elles méritent d’être qualifiées d ’" erreurs classiques "...

Cette section énumère trois douzaines d’erreurs classiques. J'ai personnellement vu chacune de ces erreurs commises au moins une fois et j'en ai moi-même fait beaucoup ...

Le dénominateur commun dans cette liste est que vous n'obtiendrez pas nécessairement un développement rapide si vous évitez l'erreur, mais vous obtiendrez certainement un développement lent si vous ne l'évitez pas ...

Par souci de commodité, la liste a été divisée selon les dimensions de développement rapide des personnes, processus, produits et technologies.

Gens

# 1: motivation minée ...

# 2: Personnel faible ...

# 3: Employés à problèmes non contrôlés ...

# 4: Héroïque ...

# 5: Ajouter des personnes à un projet en retard ...

# 6: Les bureaux bruyants et encombrés ...

# 7: Friction entre développeurs et clients ...

# 8: attentes irréalistes ...

N ° 9: Manque de parrainage de projet efficace ...

N ° 10: Manque de participation des parties prenantes ...

# 11: Manque de saisie de l'utilisateur ...

# 12: La politique placée au-dessus de la substance ...

# 13: Réflexions fantasques ...

Processus

# 14: Horaires trop optimistes ...

# 15: Gestion des risques insuffisante ...

# 16: Echec de l'entrepreneur ...

# 17: Planification insuffisante ...

# 18: Abandon de la planification sous pression ...

N ° 19: Temps perdu pendant le front flou. Le "front flou" est le temps qui s'écoule avant le début du projet, le temps normalement consacré au processus d'approbation et de budgétisation ...

N ° 20: Activités en amont en mutation ... Aussi appelé "saut dans le codage" ...

# 21: Conception inadéquate ...

# 22: Assurance qualité échangé ...

N ° 23: Contrôles de gestion insuffisants ...

N ° 24: Convergence prématurée ou trop fréquente. Peu de temps avant la sortie prévue d'un produit, il y a un besoin urgent de le préparer: amélioration des performances du produit, impression de la documentation finale, incorporation des crochets du système d'aide final, finition du programme d'installation, fonctionnalité inutile. prêt à l'heure, et ainsi de suite ...

# 25: Omettre les tâches nécessaires des estimations ...

# 26: Vous comptez vous rattraper plus tard ...

N ° 27: Programmation de type code-enfer. Certaines organisations pensent qu'un codage rapide, souple et complet est une voie vers un développement rapide ...

Produit

# 28: Exigences en plaqué or. Certains projets ont plus d'exigences que nécessaire dès le début ...

N ° 29: fluage des fonctionnalités ...

# 30: Plaquage en or pour développeur. Les développeurs sont fascinés par les nouvelles technologies et sont parfois impatients d’essayer de nouvelles fonctionnalités ... - que ce soit nécessaire ou non dans leur produit ...

# 31: Pousse-moi, tire-moi de la négociation ...

N ° 32: Développement orienté vers la recherche. Seymour Cray, le concepteur des supercalculateurs Cray, affirme qu'il ne cherche pas à dépasser les limites techniques dans plus de deux zones à la fois car le risque d'échec est trop élevé (Gilb, 1988). De nombreux projets logiciels pourraient tirer une leçon de Cray ...

La technologie

N ° 33: syndrome de balle d'argent ...

N ° 34: Économies surestimées grâce à de nouveaux outils ou méthodes ... Un cas particulier d'économies surestimées se produit lorsque des projets réutilisent du code provenant de projets précédents ...

N ° 35: Changer d'outils au milieu d'un projet ...

N ° 36: Absence de contrôle automatisé du code source ...

Plus grand projet = plus de complexité
Plus de complexité = plus d'incertitudes
Plus d'incertitudes = plus difficile à estimer plus
difficile à estimer = de mauvaises estimations De
mauvaises estimations = des dépassements de coûts

Je blâme le processus d'enchères. Il récompense le groupe qui peut donner l'impression que la transaction est la moins chère / la plus rapide sur papier.

Les personnes qui préparent des offres ne veulent pas perdre leur temps si elles n’ont aucune chance de gagner. Par conséquent, leurs estimations normales sont mises en attente. Je connais des personnes qui ont spécifié des commutateurs normaux au lieu des commutateurs POE pour économiser 80 $. Mais le projet avait besoin de POE car il avait des caméras IP. Ces 80 $ doivent être dépensés, mais maintenant, ils ne font pas partie des spécifications.

J'ai la ferme conviction qu'un projet de 2 mois à 2 000 000 $ prendra encore 2 mois à 2 000 000 $, quel que soit le nombre d'enchères que vous recevez. Si vous pensez que faire les choses correctement coûte cher, attendez de voir à quel point il est coûteux de faire les choses mal.

Une des raisons possibles est que les estimations sont basées sur des projets plus petits, en supposant une croissance linéaire du coût en fonction de la taille du projet, alors que la croissance des coûts est par exemple quadratique en raison de la complexité croissante, de la durée plus longue du projet (plus de temps pour la modification des exigences), etc. difficile, et plus le projet est volumineux, plus il est difficile d’estimer correctement.

Une autre raison tient aux estimations biaisées par optimizm: pour gagner l'appel d'offres, des estimations optimales sont utilisées pour calculer le prix. Plus le projet est vaste, moins le scénario est probable. Les règles d'enchères font qu'il est probable que l'acquéreur le plus optimiste obtienne l'acceptation. Ainsi, même si 5 fournisseurs font une estimation réaliste et que le 6ème est trop optimiste, l'optimiste remporte l'appel d'offres et échoue plus tard. C'est donc une sorte de sélection négative.

Le coût n’empêche pas le calendrier aux yeux de la «direction», ce qui est une distinction importante à faire. Comme nous le savons, "neuf femmes ne peuvent pas avoir un bébé en un mois" , mais vous seriez surpris de voir combien de personnes pensent que les problèmes s’atténuent par rapport à l’argent qui leur est jeté. Une mauvaise gestion de projet, qui se manifeste souvent sous la forme d'une micro-gestion, est la principale cause de la plupart des projets en attente (selon mon expérience). La micro-gestion entre en action lorsque la «direction» se rend compte que quelque chose devient incontrôlable et qu'elle ne comprend pas pourquoi.

Lorsque ce n’est pas la cause, les résultats attendus du projet n’étaient probablement pas prévisibles. D'après mon expérience, si la durée d'un projet est trop courte, les gens auront tellement peur de commettre des erreurs qui entraînent un «double travail» qu'ils ne font pas grand chose du tout.

C’est la raison pour laquelle la direction devrait être peuplée de programmeurs chevronnés qui ont toujours dirigé des équipes qui ont produit des projets réussis. Une telle personne pourrait dire: "Nous ne pouvons absolument pas faire cela de manière responsable" malgré les revenus possibles et ne serait pas en gestion longtemps, ce qui explique pourquoi beaucoup d'entre nous (en fin de compte) répondons au MBA au lieu du PHD.

J'ai perdu le compte du nombre d'entreprises pour lesquelles j'ai travaillé où un non-programmeur était en charge de l'embauche de programmeurs. Une fois, lors d’une interview, le responsable du recrutement n’a voulu parler que d’un événement sportif récent (je pense que c’était un match de football). Si la personne que vous dirigez s’inspire davantage de l’entraîneur de la NFL que de Knuth, le projet va déborder.

De temps en temps, vous rencontrez quelque chose de bien planifié, bien compris, réaliste et apparemment simple. Pour une raison quelconque, six mois après le début du développement, tout s'est inversé. Ça arrive. Cependant, il est rare que la cause sous-jacente d’un projet devienne un tonneau de porc glorifié.

Néanmoins, je dois admettre que si vous regardez les informations, vous pourriez voir un accident de moto occasionnel ou un accident de train. On n'entend jamais parler de millions de motos ou de trains qui arrivent à l'heure tous les jours sans incident. La même chose va avec les projets. Bien sûr, il est intéressant de voir une autopsie publique de quelque chose qui a vraiment mal tourné, mais on n'entend presque jamais parler de choses qui se sont vraiment bien passées. Je pense que les projets blindés sont toujours l'exception, pas la norme.

La plupart du temps, une combinaison de deux ou plusieurs des éléments suivants:

• problème de collaboration entre les départements
• la politique ... trop de politique ...
• mauvaise équipe
• calendrier irréaliste
• changer de périmètre sans la méthodologie appropriée
• informations manquantes

Beau livre sur le sujet: Death March .

Les gens ont tendance à penser que le développement de logiciels est un processus prédictif, essayant de mesurer et d'estimer les choses un an à l'avance. Ce n'est pas possible! Le logiciel de construction n'est pas la fabrication de boulons.

Suivant la même "tendance", ils essaient de faire une grande analyse (encore une année à l’avance) en pensant couvrir toutes les possibilités, puis en transformant les programmeurs en simples dactylographes. Comment se fait-il que cela puisse fonctionner? Ce type de comportement conduit à de mauvaises estimations et à beaucoup de bureaucratie.

Plus le projet est important, plus vous travaillez pour une grande organisation. Plus l'organisation est grande, plus il y a de couches de gestion. Plus il y a de niveaux de gestion, plus il est difficile d'obtenir de mauvaises nouvelles ("nous ne pouvons pas avoir ce que nous voulons, mais ce que nous pouvons nous permettre") pour en faire une chaîne de commandement. Moins les mauvaises nouvelles sont susceptibles de faire partie de la chaîne de commandement, plus un plan imaginaire sera accepté et maintenu longtemps après que l'on sait qu'il est intenable.

Les projets logiciels de toutes tailles "ont tendance à échouer" ou "ont des dépassements de coûts". Vous n'entendu parler du dépassement des coûts à l'entreprise autour du coin, mais vous faites entendre des choses comme le FBI système de cas virtuel ou le système de manutention des bagages de l' aéroport de Denver. Je vais donc affirmer que tous les grands systèmes ne tombent pas en panne, pas plus que tous les grands systèmes ont des dépassements de coûts / délais.

Je suis tombé sur de gros systèmes qui sont arrivés à temps (le calendrier avait été déplacé une fois et une seule au cours du projet) et sur les spécifications (je n'avais pas accès aux informations budgétaires car nous n'étions qu'un des nombreux fournisseurs). Un de ces systèmes qui m'impressionne encore (et j'en ai écrit un peu sur ce site) est un grand système de gestion de la clientèle intégré destiné à un grand client financier (parmi les 100 premiers de la fortune 500). J'estime qu'ils ont dépensé environ 100 000 dollars par jour (pendant plus d'un an) sur les salaires des personnes lors des conférences téléphoniques.

Dans le cas du système de traitement des bagages, les responsables du logiciel ont déclaré: "Sur la base de projets de cette taille et de cette complexité, il faudra 4 ans pour construire et déboguer ce système". Les directeurs des ventes et de la direction ont déclaré: "L’aéroport ouvre ses portes dans 2 ans, nous avons dit au client que cela prendrait 2 ans, vous avez donc 2 ans pour le faire." Le test permettant de savoir si vous êtes un programmeur ou un mauvais gestionnaire est une réponse simple à la question suivante: "le système de traitement des bagages était-il en retard ou à l'heure?"

Si le client sait exactement ce qu'il veut (et très peu le savent), il sera très loin de maîtriser les coûts et les délais (et ce sont ces gens-là qui ont tendance à effectuer des délocalisations assez bien). Si votre projet doit respecter toutes les caractéristiques possibles imaginables par vos clients, et que chaque département dispose d'un droit de veto lorsque ses briques dorées pour animaux de compagnie sont ajoutées au projet, vous êtes voué à l'échec dès le début (comme le FBI). Projet VCF).

Perception de la réalité

Voici la meilleure description de ce problème que j'ai jamais trouvée. Tree Swing à partir de businessballs.com

Le concept de «perception de la réalité» m'a été présenté très tôt dans ma carrière de programmeur. Pour cela, je suis vraiment reconnaissant. Je pense que c'est la principale raison de l'échec de tout projet, pas seulement des projets informatiques .

L'une des raisons des échecs est qu'un grand projet est généralement un projet de grande envergure, important pour l'entreprise. Lorsque les projets et les tâches occupent une place importante, cela encourage les gens à mentir.

Votre patron veut que vous estimiez que votre état d'achèvement est élevé. Il veut estimer les dépassements et les retards du côté des plus faibles. Lorsque vous rencontrez un problème, il ne veut pas entendre dire que cela va ajouter trois semaines à la tâche. il veut entendre que vous pouvez travailler en quelques heures ce soir.

Et ainsi de suite.

J'étais sur un projet il y a plusieurs années, pour un client. J'ai été amené après la soumission et le plan de projet ont été achevés. Il y avait une pression constante pour aller plus vite, des décisions de réduction de coûts ridicules, une surcharge de personnel, pas de ressources pour eux; pas de bureaux, ordinateurs, rien.

Enfin, j'ai découvert que le projet avait été proposé à 7 mois et à 16 millions de dollars. J'ai estimé au verso d'une enveloppe que cela devrait être de 24 mois et de 50 à 100 millions. J'ai organisé une réunion avec mon supérieur hiérarchique et son supérieur hiérarchique, puis j'ai présenté mon cas et expliqué comment nous n'allions PAS arriver à livrer dans les délais impartis ni dans les limites du budget imparti. ils ont minimisé tous les problèmes. À la fin de la réunion, le CIO a appelé et a dit à ces gestionnaires ce que j’avais dit, à l’exception de la faille dans la soumission initiale.

J'ai eu la chance d'abandonner le projet quand ils ont changé de technologie en une technologie pour laquelle je ne connaissais pas les compétences. J'ai parlé avec quelqu'un beaucoup plus tard. Le projet a finalement été annulé à peu près à la moitié… à 12 mois et 35 millions de dollars.

Les projets de grande envergure découragent les gens en disant: "c'est une erreur". Les erreurs ne sont pas tolérées.

Un peu plus sur la réponse de VonC:

Ces grands projets ont tendance à avoir une mentalité de "tout ou rien". Le projet tel que défini doit être publié en une fois, souvent car il s'agit d'un changement de système existant.

Cela signifie que les problèmes de fluage des fonctionnalités / exigences sont plus difficiles à résoudre. Ainsi, lorsque le projet se concrétise, il est souvent considéré comme ne répondant plus aux exigences. Cela peut être exacerbé si le système existant a été mis à jour ou si la technologie a évolué entre-temps.

Quelle est la solution à cela?

Je ne le sais pas vraiment car personne ne veut avoir deux systèmes fonctionnant en parallèle avec un ensemble de fonctions changeant réparties entre les deux.

La complexité des grands projets peut être grandement exacerbée par des pressions politiques externes. Un ministère peut avoir une idée très claire et précise de ce qu’il veut dans le nouveau système, mais les ministères associés lui adressent une douzaine de demandes du type "Eh bien, tant que vous le faites, pourquoi ne pas faire cette petite tâche secondaire pour nous aussi? " Vous pouvez commencer par dire «Non, c'est hors de propos», mais les affrontements politiques entre les personnes condamnées commencent, et le budget du projet est menacé à moins que tout le monde ne prenne sa part du gâteau.

Pendant des années, notre police locale n'a pas pu rechercher des plaques partielles dans le système de véhicules à moteur, une caractéristique qui semble absurdement simple. J'ai demandé à un ami ce qu'il était si difficile d'ajouter cette fonctionnalité, et ils m'ont dit que chaque fois qu'ils proposaient de passer à une base de données moderne, tous les autres départements de l'État en interaction avec le système de véhicules à moteur souhaitaient obtenir leur part de le système fixe aussi. Le résultat a été un verrouillage complet du cadre de la modernisation informatique. Enfin, l’État a réuni suffisamment de capital pour mener à bien un effort de modernisation à l’échelle du système, qui a ensuite échoué parce qu’il était complexe.

Un facteur qui a été abordé mais pas encore abordé:

Presque tous les échecs dramatiques sont des contrats qui ont été soumissionnés. Qu'advient-il d'une entreprise compétente dans une telle situation? Ils font une estimation réaliste et sont donc presque certainement sous-évalués par quelqu'un qui a fait une mauvaise estimation.

Si l'entreprise ne peut pas estimer correctement, est-ce surprenant qu'elle ne puisse pas également construire un système correctement?

Michael Krigsman sur ZDNet a un blog consacré aux " Échecs de projets informatiques ", qui pourrait être intéressant ici.

Un autre point est qu'avec les longs projets couvrant plusieurs années, il y aura généralement des mises à niveau à envisager ou des solutions alternatives, par exemple, un projet peut-il maintenant être réalisé dans le cloud plutôt que sur site si quelque chose commence à apparaître de plus en plus, ceux-ci ce n'était pas une donnée lorsque le projet a été démarré. Par exemple, bien que l'on puisse démarrer alors que quelque chose est à 6.0, au moment où la première phase est terminée, il peut bien y avoir une sortie 6.3 ou 6.4 et la question de savoir quand la mise à niveau est demandée. Les modifications apportées à la portée et aux fonctionnalités souhaitées, soit parce que les exigences n'ont pas été correctement rassemblées, soit parce que quelqu'un a changé d'avis, sont deux autres points qui ont déjà été abordés.

Peut-on utiliser agile dans ce genre de projets ou l'approche traditionnelle reste la meilleure.

La raison pour laquelle les processus agiles bien appliqués ne semblent pas souffrir autant de ce problème est due à une raison simple. Vous ne pouvez pas démarrer un grand projet de manière agile. Vous pouvez choisir l'un ou l'autre.

Avec un processus agile, vous ne regardez jamais vraiment au-delà d'une ou deux itérations dans l'avenir du projet. il n'y a pas de «plan» pour les 2 prochaines années, seulement les deux prochaines semaines. Lorsque votre point de vue est aussi court, vous devez faire quelques compromis. Vous ne pouvez jamais commencer avec un plan pour créer "Le dernier mot dans les widgets", quel que soit le type de widget que vous concevez. Tout au plus, vous pouvez commencer par "Un widget qui peut frob", car c’est à peu près tout le travail que vous pouvez faire en une ou deux itérations.

La bonne chose à ce propos est qu'après quelques itérations vous avez déjà un produit fini et fonctionnel que quelqu'un peut trouver utile, en particulier un client qui a désespérément besoin d'un widget qui peut frob et zort.

Essentiellement, les grands projets peuvent échouer car ils visent à résoudre tous les problèmes de tous les clients potentiels. Un projet agile n’a jamais cet objectif, mais dans chaque version, il n’est question que d’un seul problème critique pour un seul client. Après un long moment, cependant, un projet agile pourrait résoudre beaucoup de problèmes critiques pour beaucoup de clients.

• Défaut d'expédition aux utilisateurs réels

Les grands projets ont la fâcheuse tendance à passer au mode «infrastructure» pendant des années et à oublier de créer de véritables fonctionnalités pour les utilisateurs finaux et de les expédier. À la livraison, les modifications sont très coûteuses et, généralement, les plus gros changements conceptuels sont demandés après le premier véritable test bêta.

• Défaut d'estimer avec précision le coût

Si les projets semblent dépasser leur retour sur investissement, ils sont annulés.

• Défaut de contrôler la qualité

Avec suffisamment de défauts, il est possible que l’élan d’avancement tombe à zéro ou moins. Sans aucun progrès, il est difficile de plaider en faveur de la survie.

Ils ont oublié la loi de Hofstadter: cela prend toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter.

Choses que j'ai vues dans le développement Web:

• Trop de cuisiniers - Détaillant majeur B & M où l'accent est soudainement passé au Web. Soudainement, 20 chefs de département multiplient les démarches pour impressionner le nouveau fromage principal. Une fois, j’ai eu à mettre en place de nouvelles icônes car le service juridique n’aimait pas le look des anciennes.

• Concentrez vos efforts sur la nécessité de faire correspondre les spécifications aux objectifs atteints - "Les icônes d'IE6 sont légèrement fanées par rapport à celles d'IE7. Merci de laisser tomber votre travail essentiel au moment du lancement et d'assister à 0,05% de notre clientèle pour faire des choses horribles qui prendront des jours de mettre en œuvre et de ralentir davantage l'expérience IE. "

• Mauvais outils choisis par des non-développeurs qui ne pouvaient même pas être dérangés de demander conseil à leurs développeurs internes.

• Les mauvais développeurs choisis par les outils - "Pourquoi payer à 20 développeurs Java compétents un salaire décent quand on peut sous-traiter 200 types peu avertis en code qui savent trop peu pour utiliser le contrôle de version?" comme ils travaillent simultanément et avec des personnes de différents pays, ils travaillent principalement sur les serveurs principaux pour 3 grandes applications.

• Bad / Broken Architecture (Architecture mauvaise / cassée) - Couches sur couches de code paniqué, obtenu hier, par des personnes qui ont été licenciées ou qui sont maintenant des gestionnaires.