Quand un projet est raté, on cherche presque toujours les mêmes coupables.
Le manque de temps, de budget, de ressources….
Parfois même… « les équipes ».
C’est rassurant.
Mais c’est rarement la vraie raison.
Le problème n’est presque jamais opérationnel !
Un projet qui dérape en exécution est souvent déjà condamné bien avant.
Simplement, personne ne s’en rend compte.
On pense que le problème vient :
- d’un retard
- d’un bug
- d’un manque d’organisation
Alors que ces éléments ne sont que des symptômes.
L’échec commence dès le cadrage !
Un projet mal cadré ne peut pas être bien exécuté.
C’est mécanique.
Si le besoin est flou, mal compris ou incomplet, alors tout le reste repose sur une base fragile :
- les décisions seront incohérentes
- les priorités instables
- les estimations biaisées
- les équipes désalignées
Et pourtant, le projet avance.
Parce qu’on produit.
Produire donne l’illusion d’avancer…
C’est l’un des pièges les plus dangereux.
Quand une équipe travaille, livre, développe, documente… on a l’impression que le projet progresse.
Mais produire n’est pas avancer.
Un projet avance uniquement lorsqu’il se rapproche de son objectif.
Sinon, il dérive.
Et cette dérive est souvent invisible au début.
Les décisions sont prises trop tôt (et mal)
Dans beaucoup de projets, on prend des décisions structurantes très tôt :
- choix techniques
- organisation
- roadmap
- périmètre
Le problème, c’est que ces décisions sont prises avec un niveau de compréhension encore faible.
On fige des choses… alors qu’on ne comprend pas encore le problème.
Résultat : on optimise une solution… qui n’est peut-être pas la bonne.
Le projet devient rigide… alors que le besoin ne l’est pas
Plus le projet avance, plus il devient difficile de changer :
- des dépendances apparaissent
- des coûts sont engagés
- des arbitrages ont été faits
Mais pendant ce temps, la compréhension du besoin évolue.
Et là, il y a un décalage.
Le projet est figé. Mais le besoin ne l’est pas.
Le vrai problème d’un projet raté : l’absence de remise en question !
Ce qui fait échouer un projet, ce n’est pas l’incertitude.
C’est l’incapacité à s’y adapter.
Un projet robuste n’est pas un projet parfaitement planifié.
C’est un projet qui :
- accepte de remettre en question ses hypothèses
- ajuste ses décisions en fonction du réel
- revoit son périmètre si nécessaire
Mais ça demande une chose que beaucoup d’organisations évitent : remettre en cause ce qui a déjà été décidé.
Pourquoi on ne le fait pas ?
Parce que ça coûte.
Pas seulement en argent.
Mais en ego, en crédibilité, en confort.
Revenir en arrière, admettre que le projet est raté, c’est reconnaître qu’on s’est trompé.
Et ça, peu d’organisations l’acceptent.
Alors on continue. Même quand on sait que ça ne va pas dans la bonne direction.
Ce qu’il faut vraiment surveiller…
Si vous voulez savoir si votre projet va échouer, ne regardez pas :
- le planning
- le budget
- l’avancement
Regardez plutôt :
- est-ce que le besoin est clair et partagé ?
- est-ce que les décisions peuvent être remises en question ?
- est-ce que l’équipe comprend pourquoi elle fait ce qu’elle fait ?
- est-ce que le projet s’adapte au réel ?
Si la réponse est non, le problème est déjà là.
Conclusion
Un projet n’échoue pas à cause de son exécution.
Il échoue parce qu’il a été mal compris dès le départ… et qu’on a refusé de l’admettre ensuite.
Et c’est pour ça que la gestion de projet n’est pas une question d’outils.
C’est une question de lucidité.
