Pourquoi tant de projets échouent-ils ? Une statistique souvent citée affirme que 70 % des projets échouent. Bien qu’il ne semble pas exister de source originale pour cette statistique, il est intéressant de se demander pourquoi les projets échouent. Si nous pouvons apprendre des échecs passés, nous pouvons éviter de répéter les mêmes erreurs.
Lorsque je suis devenu chef de projet pour la première fois, j'ai semblé tout apprendre sur les échecs en gestion de projet à la dure : mal estimer les délais, oublier de poser des questions clés, et hésiter à dire non.
Bien que je sois chef de projet depuis de nombreuses années maintenant, il m’est encore arrivé d’avoir des projets qui échouent spectaculairement pour toutes sortes de raisons. Dans cet article, je vais expliquer ce qui fait qu’un projet est considéré comme un échec, pourquoi les projets échouent en fin de compte, et donner des conseils pour éviter l’échec.
Quand considère-t-on qu’un projet est un échec ?
On considère qu’un projet est un échec lorsqu’il dépasse le budget, est livré en retard ou ne répond pas au périmètre prévu. Il existe toutefois souvent une certaine marge de tolérance. Les projets sont fréquemment retardés pour des raisons hors du contrôle du chef de projet (par exemple, le client n’a pas envoyé le contenu de son site web à temps).
Le périmètre peut aussi évoluer au fil du projet, à cause des changements dans les besoins du client ou des parties prenantes. Même si l’évolution non maîtrisée du périmètre peut être à l’origine d’un échec, si cela est bien géré (avec des demandes de modifications et une validation des parties concernées), cela ne conduit pas nécessairement à un échec du projet.
6 raisons courantes pour lesquelles les projets échouent & exemples
Alors pourquoi les projets échouent-ils ? Voici cinq de mes plus grands échecs en gestion de projet qui illustrent les causes fréquentes de l’échec, ainsi que les enseignements précieux que j’en ai tirés pour améliorer la réussite des futurs projets.
1. Ne pas communiquer lorsque les choses se compliquent
C’est un réflexe humain de ne pas vouloir attirer l’attention sur soi si quelque chose ne va pas et que personne ne l’a remarqué. C’est contre-intuitif pour la gestion de projet, mais la mauvaise communication explique très souvent pourquoi les projets échouent.
Je l’admets, la combinaison d’un client très difficile et d’un budget ou calendrier qui va exploser m’a parfois poussé à hésiter un peu trop longtemps avant d’informer un client de l’état de son projet.
C’est d’autant plus vrai lorsqu’un projet est calme et que tout semble aller bien depuis quelques jours ou semaines. C’est justement à ce moment-là que le projet est le plus vulnérable — il est crucial de maintenir et renforcer la confiance que le client accorde au chef de projet.
Leçon retenue :
Chaque fois que je suis sur le point d’hésiter avant d’annoncer une mauvaise nouvelle à un client, je me demande : vaut-il mieux gérer ses attentes maintenant ou dois-je affronter les conséquences quand il sera trop tard ? La réponse est de toujours y aller tout de suite et être proactif.
Vous poserez aussi les bases pour gérer les attentes irréalistes à venir lors de la collaboration avec ce client.
2. Ne pas respecter le périmètre convenu
Sur un projet particulièrement détaillé, un membre de l’équipe travaillant étroitement avec moi a suggéré d’essayer un nouveau plugin de slider pour la section portfolio du site d’un client sur laquelle nous travaillions.
Il utilisait un framework avec lequel nous n’avions pas l’habitude de travailler, mais le slider semblait plus élégant et fonctionnait mieux que celui que nous utilisions habituellement. J’étais hésitant au départ, à cause du calendrier serré et des exigences précises du design, mais j’ai fini par accepter, espérant offrir une meilleure solution au client ET à notre équipe de développement.
Ce n’était pas quelque chose que nous avions envisagé de changer dans nos outils habituels, mais le moment semblait opportun et c’était une bonne occasion de découvrir ce nouveau plugin en pratique.
Ce fut finalement l’une des décisions les plus coûteuses du projet, autant en nombre d’heures qu’en budget. Le slider ne supportait pas une fonctionnalité clé et ne s’adaptait pas facilement en responsive ni à certains navigateurs.
Cela n’a pas été validé ni analysé comme modification planifiée avec les référents techniques et développeurs. Une erreur toute simple qui nous a finalement coûté beaucoup de stress, d’embarras et de ressources gaspillées, à lui comme à moi.
Ajouter inutilement des nouveautés au projet ou compliquer les tâches (« sur-qualité ») est également une cause classique d’échec.
Leçon retenue :
Respectez vos processus et n’apportez pas de changements sur un coup de tête. Si votre équipe a réellement besoin de nouveaux outils ou d’un changement de processus (y compris le logiciel de gestion de projet ou d’autres outils de gestion de projet ou technologies) en cours de projet, procédez à une analyse complète avant toute modification.
3. Devenir trop proche de son équipe ou de ses clients
Il existe une véritable frontière entre les relations professionnelles et les amitiés informelles, et j’ai appris à bien les séparer à force de pratique.
Cela ne veut pas dire que vous ne pouvez pas être ami avec vos coéquipiers ou vos clients—mais il faut juste savoir quand activer ou désactiver la posture professionnelle lors de vos échanges.
Il y a quelques années, j’ai travaillé dans une entreprise composée de jeunes fraîchement sortis de l’université, partageant tous des centres d’intérêt similaires et vivant près les uns des autres dans la même ville. Naturellement, nous passions du temps ensemble après le travail et le week-end, ce qui a favorisé de solides amitiés.
Un jour, j’ai dû demander un traitement très rapide sur un projet que personne n’aimait vraiment—ce n’était ni esthétique, ni amusant, ni quelque chose que la plupart des gens voyaient ou appréciaient.
Le designer du projet a dépassé la date limite et travaillait plutôt sur la conception d’un site plus vaste et moderne dont la livraison n’était prévue que plusieurs semaines plus tard. Je l’ai confronté et il m’a demandé pourquoi j’étais dur avec lui alors que nous étions amis.
Le brouillage des frontières entre le personnel et le professionnel est parfois la raison pour laquelle les projets échouent, car cela peut impacter la responsabilisation de chacun.
Leçon retenue :
Soyez amical, mais restez professionnel pour maintenir la responsabilité de chacun sur un projet. Il est bien plus facile de penser qu’on a droit à un « passe-droit » entre amis, et cela peut mener à des situations risquées (et embarrassantes) si cela se mélange avec les obligations professionnelles.
4. Paniquer avant d’avoir pris le temps de réfléchir
C’est peut-être juste moi, mais je trouve qu’il est facile de réagir à certains signaux d’alerte ou mots-clés sur les projets.
Des choses comme des e-mails EN MAJUSCULES, les mots « nouvelle date limite » ou « site indisponible », ou des signes avant-coureurs plus subtils comme une absence de communication à un moment-clé du projet, l’ajout d’un nouvel intervenant peu avant le lancement, ou des bugs étranges sur un site juste avant une démo pour le client.
Rien ne me stresse plus que de demander instantanément à un manager, un développeur ou un client des clarifications sur quelque chose qui aurait été évident (ou faisable par moi-même) si j’avais juste pris le temps de souffler, de réfléchir et de planifier ma prochaine action.
Il m’est arrivé de nombreuses fois de penser qu’un site avait un bug majeur (alors qu’il s’agissait seulement d’un problème de cache chez moi ou chez le client), de mal interpréter une demande de fonctionnalité paraissant immense alors que c’était bien plus simple, ou de constater qu’un client pensait que son site/serveur était en panne alors qu’il n’était tout simplement pas connecté à Internet (oui, ça arrive souvent).
Bien que ce point ne soit pas à lui seul un grand échec, il contribue à de mauvaises communications et peut provoquer la panique quand elle n’est pas nécessaire.
Leçon retenue :
N’ayez jamais peur de prendre du recul face à un e-mail ou message réactif, de faire une pause, et de prendre un moment pour enquêter avant de demander plus d’aide.
5. Ne pas suivre les processus
Ah oui : le fameux « cet élément peut se passer de notre habituel processus dev/design/relecture/QA parce que c’est juste un petit changement ». C’est très souvent la raison de l’échec des projets.
Je l’ai vu se produire tellement de fois sur des projets. J’ai moi-même commis cette erreur avec des mises à jour de maintenance présentées comme « faciles », de petites demandes de fonctionnalités sur de gros projets, et des changements de périmètre en tout genre.
Quelque chose qui semble aussi simple que la modification d’une option dans un champ de formulaire peut très vite tourner au cauchemar et nécessiter une refonte système complète quand un développeur commence à s’y plonger.
De la même manière, un client qui demande un petit changement visuel peut bouleverser le processus de conception et vous amener à repenser une partie du flux du site.
Leçon retenue :
Ayez toujours confiance dans le processus et suivez les étapes de découverte, d’estimation et de contrôle qualité comme il se doit : j’ai appris qu’il n’y a jamais de modification trop petite pour ne PAS risquer de perturber autre chose en cours de route.
Protégez votre processus et imposez la rigueur de faire les choses dans les règles, même si cela demande un petit effort supplémentaire. Cela signifie aussi choisir la bonne méthodologie de gestion de projet ou le workflow approprié, que ce soit agile, cycle en V, Kanban ou une approche hybride.
6. Ne pas définir d’objectifs clairs
Dès le départ, les projets doivent avoir des objectifs clairs et mesurables (aussi appelés objectifs SMART). Comment savoir si l’on travaille sur un projet réussi si l’on n’a rien à quoi comparer les avancées du projet ?
Dans la phase de planification, vous allez déterminer les jalons du projet, les objectifs et les indicateurs de réussite. Pensez à votre planning projet, vos exigences et votre budget. Choisissez les KPIs qui font le plus sens pour votre initiative ou projet.
C'est l'une des causes d'échec les plus courantes. Sans cela, les membres de l'équipe projet (et vous-même !) ne sauront pas si vous respectez le calendrier, le périmètre et le budget. Vous accumulerez les échéances manquées et les dépassements de budget avant même de vous rendre compte qu'il y a un problème.
Leçon retenue :
Établissez toujours des KPI et des indicateurs pour vos projets, même pour les plus petits où cela peut sembler superflu ou comme une étape supplémentaire pour confirmer quelque chose que vous pensez déjà savoir. Vous pourriez découvrir un écart entre vos objectifs et vos indicateurs qui pourrait vous éviter bien des soucis à l'avenir.
3 étapes pour éviter l'échec d'un projet
Une approche pour éviter l'échec d'un projet consiste à effectuer des évaluations de projet à plusieurs étapes tout au long du projet. Voici trois étapes à garder à l'esprit :
- Identifier les risques : En général, cela fait partie du processus de création du plan de projet. Consignez les risques dans un registre des risques ou un journal RAID.
- Évaluer les risques : Évaluez la probabilité et l'impact de chaque risque. Les risques les plus probables et susceptibles d’avoir le plus d’impact négatif doivent être surveillés de près.
- Créer des plans de gestion des risques et des plans de contingence : Que ferez-vous si un risque se réalise ? Comment pouvez-vous réduire la probabilité de voir ce risque survenir ?
En savoir plus sur comment éviter l’échec d’un projet ici.
Qu'en pensez-vous ?
Ce ne sont là que quelques-unes des raisons les plus courantes de l’échec d’un projet, mais il en existe d'autres. Vous pouvez également être confronté à un manque de ressources, à une absence de travail d’équipe et à divers autres problèmes. L'essentiel est de rester vigilant, de maintenir les canaux de communication ouverts et de vous assurer d’avoir anticipé les risques pouvant menacer votre projet.
Améliorez vos compétences en gestion de projet avec l’un de ces cours approfondis de gestion des risques.
