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.