Le pourquoi de l’échec des projets logiciels

Tout n’a pas encore été écrit sur les causes de l’échec des projets logiciels. Un nouveau rapport aborde une fois encore le sujet.

Tout n’a pas encore été écrit sur les causes de l’échec des projets logiciels. Un nouveau rapport aborde une fois encore le sujet.

Alpha Software, un développeur de logiciels de base de données, a examiné les raisons menant à la faillite des projets logiciels. Le rapport est certes truffé de critiques sur la concurrence, mais quiconque le parcourt attentivement y trouvera aussi des analyses pertinentes des raisons de l’échec des projets. Selon l’auteur, il y en a en gros trois: des erreurs de processus, du logiciel et du matériel insuffisants, et une piètre gestion de la part du management.

L’auteur, David Moskovitz, mentionne d’abord un certain nombre d’erreurs qui peuvent se manifester dans le processus: implémentation de spécifications désuètes, manque de communication avec le client, développeurs qui doivent travailler simultanément sur de nombreux projets, ce qui leur fait perdre chaque fois du temps, parce qu’ils doivent se remettre au courant, un travail qui semble inutile du fait qu’au cours du projet, les priorités changent, sans compter les schémas d’agenda irréalistes, les budgets trop spartiates et les exigences de rapportage qui entraînent pas mal de notes sur papier.

L’auteur distingue une deuxième raison principale à l’échec des projets: du logiciel et du matériel insuffisants. Il met ainsi le doigt sur des problèmes d’échelle et de capacité qui se manifestent furtivement, sur des bogues dans les outils logiciels, voire sur des problèmes qui surgissent du fait que le poste de travail du développeur n’est plus assez puissant pour accepter une nouvelle version de l’environnement de développement.

Les carences du management exigent aussi leur tribut, selon l’auteur. C’est notamment le cas, lorsque la direction ne soutient pas suffisamment un projet logiciel. Sur ce plan, il y a aussi le choix d’un outil ou d’un fournisseur déterminé qui peut causer des problèmes (sous prétexte que l’outil s’est acquitté de sa tâche dans un projet précédent).

L’une des solutions envisagées par Alpha Software consiste à recourir au ‘risk assessment’ (évaluation des risques et de leurs coûts) à un ou plusieurs moments du processus de développement. Lors de la sélection des outils, il convient en outre de suivre les règles ‘MoSCoW’ (‘Must have, Should have, Could have, Want to have sometime’) pour délimiter les priorités. De plus, Alpha Software cite encore l’importance de la connaissance du support du fournisseur: un produit est-il encore supporté par son fabricant ou pas?

Vous pourrez découvrir le rapport complet [ici].

En collaboration avec Computable