Echecs projets : encore et toujours la même histoire ?

La première source de problèmes se retrouve pratiquement dans tous les projets en difficulté : la gestion de besoins.

Lorsque vous demandez sur un projet comment sont formalisés les besoins, les regards gênés font place à de malheureuses tentatives : on ressort le cahier des charges, la réponse du prestataire, le début des spécifications détaillées sous Word, rapidement abandonnées au profit d’une approche plus légère.
Les développeurs eux de toute manière ont codé d’après ce que leur chef de projet leur a dit, alors les spécifications écrites…
Il serait injuste d’oublier d’autres variantes tout aussi classiques :
* Besoins formalisés mais décalés avec les besoins réels, décalage qui remonte généralement à la surface au moment de la livraison finale.
* Besoin fonctionnels formalisés sans prise en compte de contraintes techniques ou de risques sous-jacents.
* Développement réalisés sans expression de besoin.

Je connais ces causes d’échec. Vous les connaissez. La plupart des chefs de projet les connaissent. Et pourtant elles se perpétuent inéluctablement. Pourquoi ? La plupart du temps parce que l’on veut trop bien faire au départ. Des spécifications écrites détaillées, trop détaillées, conduisent toujours à la catastrophe. Parce qu’on en vient jamais à bout. Parce que 100 pages de spécifications ne signifient rien pour un développeur. Parce que tout va bouger. Parce que personne ne pourra plus faire le lien entre ce qui a été codé par les développeurs et ce qui avait été défini au départ. Parce que chacun, en fonction de son rôle (MOA, Chef de projet, développeur) a envie de suivre les besoins avec ses outils habituels, tous différents (Word, Project, environnement de développement). Parce qu’il faut une approche radicalement plus pragmatique de la gestion des besoins.
Un échec ne se traduit pas systématiquement par la non livraison d’une solution. Parfois, c’est le refus par l’utilisateur final de la solution développée qui traduit un échec.