Comment éviter l’échec d’un projet en 3 étapes + 4 études de cas
Il existe de nombreuses raisons pour lesquelles les projets échouent, mais elles se résument généralement à l'une des deux suivantes (et parfois les deux) :
- Il y avait un risque que personne n’a reconnu, et/ou
- Nous n’avons pas bien réagi lorsqu’un problème est survenu
Dans cet article, je veux me concentrer sur la vue d'ensemble afin d'aborder la principale cause d’échec des projets — et souvent aussi de la gestion de projet.
Voici comment éviter l’échec d’un projet, et que faire si ce problème catastrophique que vous n’aviez pas anticipé se produit (vous pouvez encore vous en sortir si vous agissez rapidement et avec réflexion !).
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Qu’est-ce que l’échec d’un projet ?
Exactement ce que cela signifie : chaque fois qu’un projet ne répond pas aux objectifs fixés par l’équipe au début, ne répond pas aux attentes du client ou des parties prenantes clés ou n’est pas respecte les délais, le budget ou la portée.
Pourquoi les projets échouent-ils ?
Comme je l’ai mentionné en introduction, il existe une variété de raisons courantes pour lesquelles les projets échouent. Habituellement, cela est dû à un risque qui n’a pas été correctement évalué et/ou à une mauvaise gestion de ce risque par l’équipe (y compris le chef de projet).
D’autres raisons fréquentes d’échec d’un projet peuvent inclure une communication insuffisante sur l’avancement, les problèmes ou les risques ; des membres de l’équipe qui ne respectent pas (ou ne comprennent pas correctement) le périmètre du projet, les livrables (c’est-à-dire la dérive du périmètre) ou les délais ; un manque de ressources, ou encore l'absence d’adhésion aux processus ou méthodologies désignés.
Comment éviter l'échec d'un projet : 3 étapes
La gestion des risques est une activité clé en gestion de projet. Elle est si importante que l’échec dans la gestion des risques conduit bien souvent à l’échec du pilotage même du projet. La gestion des risques comprend trois grands volets :
- Identifier les risques.
- Évaluer ce que vous avez identifié : quelle est la probabilité que cela se produise et quelles seraient les conséquences ? Quels sont la probabilité et l’impact ?
- Préparer des plans d’atténuation et de contingence pour les risques qui pourraient couler votre projet pourtant bien parti. Les registres de risques sont pratiques pour suivre ce que vous avez fait.
1. Identifier les risques
Commencez par identifier les risques. Bien réaliser cette étape augmentera considérablement vos chances de succès. Et même s’il est difficile de tous les détecter, une analyse systématique du projet permet souvent de mettre en évidence les risques majeurs. Cette étape s’inscrit généralement dans le processus d’élaboration du plan de projet.
Mon expérience se situe dans le développement logiciel, produit comme IT, et dans ses processus associés. Les projets logiciels sont complexes, fragiles, et sauf rares exceptions, ne disposent pas des dispositifs de sécurité et d’inspection intégrés que l’on trouve, par exemple, dans la construction ou la fabrication de dispositifs médicaux.
Vous devez définir des objectifs de projet sur chacun des quatre axes :
- Calendrier
- Contenu
- Coût
- Qualité
Si vous ne savez pas quels sont ces axes, c’est votre point de départ. Je constate généralement que deux des quatre axes évoluent un peu, mais plus vous comprenez où vous allez, plus il sera aisé d’identifier les obstacles.
Savoir quel est l’axe prioritaire parmi les quatre vous aidera à réduire les risques en effectuant les arbitrages appropriés.
Il est facile de se focaliser sur le calendrier du projet et de manquer des risques pouvant impacter les autres axes, mais ils sont tous liés et tous importants à identifier.
Atteindre vos objectifs de délais avec un produit défectueux n’est généralement pas une bonne option — même en le livrant, vous finirez par faire des versions correctives qui repoussent davantage l’échéance pour un produit satisfaisant que si l’on avait traité le problème à la source.
Au-delà des 4 axes
En plus des quatre axes, trois aspects sont à équilibrer dans votre projet :
- Le produit, généralement couvert par les axes
- Le processus
- Les personnes
Les risques liés au processus sont de deux sortes : une inadéquation du processus existant qui ne répond pas aux besoins du projet, ou l’absence de processus pour un point critique de l’activité de votre équipe. Ces risques sont généralement assez simples à maîtriser en créant ou corrigeant le processus concerné.
L’aspect humain est souvent sous-estimé, mais c’est votre équipe, et les équipes avec lesquelles elle interagit, qui feront la réussite ou l’échec du projet. Des parties prenantes difficiles ou peu impliquées compliqueront l’obtention des éléments nécessaires pour avancer.
Des membres de l'équipe surmenés, stressés ou insatisfaits n'accompliront pas le travail. Certains des problèmes humains potentiels peuvent être identifiés publiquement, d'autres devront être traités en privé, mais ne faites pas l'erreur de les ignorer.
2. Évaluez les risques identifiés
Après avoir identifié les risques, déterminez quelle est la probabilité que chaque risque se réalise. J’utilise généralement un pourcentage—100 % signifie que je suis certain que cela va se produire. Il est également important d’évaluer la gravité des conséquences si le risque survient. Le moyen le plus simple est de classer les risques comme élevés, moyens ou faibles.
Une fois cette analyse réalisée, il est temps d'impliquer votre équipe. Demandez à chaque membre ou contributeur du projet ce qui l’inquiète, ajoutez ces éléments à la liste des risques et soumettez-la à l’examen :
- L'équipe peut-elle penser à d'autres risques auxquels vous n'avez pas pensé ?
- Que pensent-ils de votre analyse de probabilité et d’impact ?
Sur la base de cette réunion, vous pouvez ajuster votre plan de gestion des risques. Les parties un et deux sont terminées—pour le moment. Vous devrez revoir les risques au moins une fois par semaine pour vérifier s’il y en a de nouveaux, s’il y en a qui ne sont plus applicables, et si la probabilité ou l’impact de certains risques ont changé.
3. Préparer des plans d’atténuation et de contingence
Enfin, si la combinaison probabilité et impact de certains risques peut mettre en péril votre projet, travaillez avec votre équipe pour élaborer des plans documentés d'atténuation et de contingence.
L’atténuation consiste à rendre le risque soit moins probable, soit moins impactant s’il se réalise. La contingence se concentre sur les étapes à suivre si le risque est inévitable et survient effectivement.
Assurez-vous que les plans sont documentés et que tout le monde en a connaissance. Il est aussi conseillé de prévoir des réponses aux éventuels problèmes humains en plus des 4 leviers et du processus, mais vous voudrez sans doute effectuer cette analyse vous-même et la garder confidentielle.
Comment survivre à l’échec d’un projet
La deuxième cause des échecs en gestion de projet est une mauvaise réaction face à la réalisation d’un risque, qu’il soit anticipé ou non. Tout repose alors sur vous en tant que chef de projet. Avant de passer aux étapes suivantes, commencez par ces deux conseils :
- Ne paniquez pas. Pensez à respirer.
- N'accusez personne et n’autorisez personne à lancer une chasse au coupable.
1. Référez-vous à votre plan de contingence
Si vous disposez d’un plan de contingence, convoquez une réunion immédiatement ou, à défaut, envoyez un e-mail pour déclencher le plan de contingence. Rappelez à chacun ce qu’est le plan et indiquez à tous quand et comment transmettre les mises à jour de situation.
Si vous sautez cette étape ou la retardez, vous verrez des personnes désireuses d’aider agir dans la panique. Lorsque cela se produit, vous perdez le fil de ce qui a été fait et cela aggrave souvent la situation.
Si vous n’avez pas de plan de contingence, rassemblez immédiatement tout le monde via une convocation en réunion accompagnée d’instructions strictes : NE RIEN FAIRE D’AUTRE avant la réunion.
Sinon, chacun va essayer d’aider à sa façon et vous ne saurez plus ce qui a été fait. Lors de la réunion, énoncez clairement le problème—c’est toujours surprenant de constater combien de visions différentes il peut y avoir à propos d’un même problème.
Réalisez une analyse consolidée de la cause racine afin d’identifier la source de l’incident et d’élaborer un plan—qui fait quoi et comment procéder—pour la résolution. Lors de cette analyse, il faut comprendre qui a fait quoi avant l’incident, mais restez factuel dans la discussion.
Autrement dit, uniquement les faits. Ne cherchez pas un coupable, car cela détourne l’attention du vrai problème. Si votre équipe ne parvient pas à trouver une solution, plusieurs options s’offrent à vous.
La première consiste à faire appel à une personne compétente dans le domaine concerné mais qui ne travaille pas sur ce projet spécifique—par exemple, si le problème semble venir de la base de données, invitez un administrateur de base de données qui n’est pas impliqué sur ce projet pour apporter un regard neuf.
Une autre technique consiste à faire intervenir une personne n’ayant aucune connaissance du projet. Parfois, le fait de devoir expliquer chaque étape point par point met en évidence des hypothèses erronées ou des aspects que l’équipe avait négligés.
2. Résolvez le problème
Faites adhérer toute l’équipe à votre plan d’action et attribuez les tâches. Demandez à chacun de vous faire remonter sa progression et indiquez à quelle fréquence : à chaque heure, à la fin d’une tâche, en fin de journée ou selon le contexte.
Le reporting peut vous sembler évident mais il ne l’est pas pour tous. Les mises à jour régulières aident à ancrer l’équipe. Faites régulièrement un compte-rendu synthétique à tous.
Ceux qui n’ont pas de tâche immédiate vont s’impatienter et finiront par intervenir, sauf si vous les tenez informés en continu de l’avancement et des autres éléments.
Il est aussi très important de tenir la hiérarchie informée. Faites preuve de discernement pour juger qui doit être prévenu à chaque étape, mais communiquez régulièrement l’état d’avancement consolidé à l’ensemble de l'équipe.
3. Clôturez l’incident
Mais seulement lorsque c’est vraiment terminé. Rédigez un rapport final et passez à l’étape suivante. Laissez ensuite à l’équipe un moment pour se remettre.
4. Organisez une analyse post-mortem ou une rétrospective
Il est important de réaliser une évaluation de projet pour recueillir les enseignements tirés. Voici comment structurer cela :
- Énoncez le problème afin que tout le monde parte du même point.
- Commencez par ce qui s'est bien passé. Même dans la situation la plus désastreuse, il y a toujours quelque chose qui a bien fonctionné. Cela donne dès le début un ton complètement différent à la réunion.
- Parlez de ce qui doit être amélioré. S'il y a du temps, faites un brainstorming sur les moyens d’améliorer les choses ; sinon, attribuez des tâches et des échéances, puis faites un suivi.
Si la faute revient vraiment à quelqu’un, parlez-en avec la personne concernée — en privé. Si vous le faites en public, toute l'équipe se demandera qui sera le prochain à être embarrassé devant tout le monde.
Si vous sautez cette étape, votre équipe aura l’impression que quelqu’un s’en est tiré sans conséquence et que le problème n’a pas été résolu. Soyez factuel et faites le suivi de tout changement personnel de processus à apporter. Il s'agit de responsabilité et d'amélioration, pas de trouver un coupable.
3 exemples réels d'échecs de projet
J'ai connu ma part d’échecs de projets informatiques, même si heureusement — mais douloureusement — ils ont pu être récupérés.
Voici quelques exemples de mes propres échecs sur des projets informatiques et de développement ainsi qu’un exemple célèbre de projet échoué.
Ces exemples et études de cas d'échecs de projet devraient aussi vous donner une idée concrète des différentes façons dont un projet peut échouer et de la manière d’y faire face.
1. Le système de comptabilité
Au début de ma carrière, je travaillais chez IBM. Mon premier véritable poste consistait à reprendre un système relativement petit qui alimentait les systèmes comptables de l’entreprise. Une personne interne à IBM l'avait écrit dans un langage de programmation obscur, appelé RPG, sur un petit système.
Je ne faisais pas que gérer le projet — je gérais le système dans son ensemble (même s’il y avait un administrateur), y compris la collecte des exigences projet, le dépannage et la programmation.
Un beau jour, j’ai mis en production un nouveau programme, je l’ai exécuté et j’ai constaté une erreur. J’ai corrigé l’erreur puis relancé le programme. Le lendemain matin, j’ai reçu un appel du service comptabilité signalant la présence de doubles écritures (ce qui est catastrophique dans le domaine comptable).
Premièrement, personne n’a relu mon travail. Deuxièmement, je n’ai pas impliqué les personnes des systèmes en aval pour vérifier les écritures avant qu’elles ne s’y propagent. Troisièmement, je n'ai pas pris le temps d'analyser certains anciens programmes qui continuaient à fonctionner et à provoquer des doubles écritures. Il n’y avait aussi aucun processus, si ce n’est ce que j’inventais au fur et à mesure.
Ma réaction alors : la panique. Mon dieu, à peine sorti de l’école et je contribue à ruiner le système comptable d’IBM. Je n’ai pas inclus les bonnes personnes — l’administrateur n’était au courant de rien — et il a généré une nouvelle série d’écritures sans le savoir. Au final, j’ai travaillé 48 heures d’affilée pour remonter à la source, corriger le problème, puis développer et exécuter les programmes permettant de réparer les erreurs comptables.
Et j'ai retenu la leçon : bien regarder, faire relire, réfléchir à ce qui pourrait mal tourner, et s’arrêter pour réfléchir avant de foncer pour essayer de réparer (tout ce à quoi un logiciel de gestion de projet comptable peut aider). Imaginez maintenant que je dirige une équipe de 10 personnes et que tout le monde fasse comme moi pour résoudre le problème. Cela aurait été véritablement irréversible sans stopper l'ensemble des systèmes comptables d’IBM pour tout remettre en ordre.
2. Le nouveau produit interne
En tant que consultant, je dirigeais un gros projet neuf avec de nombreux intervenants dans la définition des besoins, ce qui entraînait des changements incessants de priorités fonctionnelles. Nous appliquions un processus de gestion de projet agile, chose inédite pour cette entreprise. L'équipe QA était excellente en tests, mais ne comprenait pas encore la logique et les attentes des utilisateurs finaux.
J'avais conscience de tout cela et je le faisais parfois remarquer, mais je n’avais ni registre des risques, ni estimation d’impact ou de probabilité, ni plan de contingence ou d’atténuation. Je n’étais pas non plus le principal relai d'information auprès du sponsor du projet, même si je la rencontrais de temps en temps.
Nous avons ajouté un sprint. Puis un autre. Ensuite, quand nous avons compris que nous n’étions pas encore prêts pour la phase de test bêta, nous avons ajouté un troisième sprint.
Parce que je n’étais pas celui qui informait directement le sponsor, je n’avais aucune idée du fait qu’elle ignorait tout ceci. La personne en charge a commis l’erreur critique de ne pas prévenir le sponsor, en espérant que nous y arriverions malgré tout.
Et honnêtement, même si je parlais de risques, je ne lui ai pas fourni d’inventaire concret à présenter au sponsor afin de la préparer à l’éventualité d’un retard de planning.
Au beau milieu de tout ça, j’ai eu une réunion avec le sponsor et j’ai évoqué, en passant, ce sprint supplémentaire que nous allions ajouter. Elle m’a interrompu. Elle n’était au courant de rien et n’était pas contente du tout.
En fin de compte, elle était plus contrariée par la surprise que par le retard du projet. L’affaire a eu des répercussions publiques et, finalement, le chef de projet a été déplacé ailleurs dans l’entreprise car la confiance était perdue.
Encore une fois, j’ai tiré des enseignements importants de cet échec. Connaître les risques n’est pas suffisant, il faut les rassembler, les évaluer, prévoir des plans de réduction et de contingence, puis les rendre publics et constamment visibles.
Je n’ai jamais eu pour habitude de cacher les risques et les problèmes, mais l'importance de la transparence dans la gestion de projet m’a paru incontestable.
3. Vous vous souvenez d’OS2 ?
Non, personne ne s’en souvient. C’est l’un des nombreux projets de développement de systèmes qui ont échoué. Je travaillais chez IBM lorsque le premier OS2 est sorti – un concurrent de Windows. Je n’ai même pas essayé cette première version car, chez IBM, nous savions tous qu’elle était vraiment bourrée de bogues. Le reste du monde s’est tout de suite aperçu qu’il y avait trop de dysfonctionnements pour que cela en vaille la peine.
C’était tellement instable que l’équipe projet ne pouvait pas imaginer que le produit était prêt, mais malgré tout, ils n’ont pas pris la bonne décision en retardant la sortie. Oublier de prendre en compte l’aspect humain, qu’il s’agisse de votre équipe ou de vos clients, risque de ruiner un plan parfait très rapidement.
En développement logiciel, il existe de nombreuses alternatives à cette situation : proposer une sortie limitée à des personnes prêtes à tolérer les bogues afin d’obtenir un logiciel de pointe, annoncer publiquement que l’on retarde la sortie pour atteindre un niveau de fiabilité conforme à ses exigences, etc.
C’était encore assez tôt dans ma carrière pour que je puisse tirer des leçons précieuses du fait qu’un produit que j’adorais était arrivé à une impasse dès la deuxième version.
Soyez clair sur vos priorités : il existe quelques cas où sortir un produit à une date précise est plus important que sa qualité, mais ils sont rares.
Utilisez vos quatre leviers, admettez vos erreurs et rendez les corrections visibles afin que les autres sachent que vous avez compris le problème et que vous ne commettrez pas la même erreur à nouveau.
Prenez en compte l’aspect humain : il est aussi crucial que la technologie. J’ai tiré ces enseignements pour mes projets logiciels et informatiques depuis cette époque, et ils se sont révélés inestimables.
En résumé
Globalement, rappelez-vous que même si c’est finalement votre responsabilité, vous n’avez pas à tout faire vous-même. En fait, il est fortement déconseillé d’essayer de tout faire en solitaire. Vous pouvez vous appuyer sur la variété des expériences et des connaissances de votre équipe. Vous êtes le chef de file, mais vous n’êtes pas obligé d’être toute l’équipe à vous tout seul.
Les logiciels de gestion de projet et autres outils de gestion de projet peuvent vous aider à suivre les risques, les jalons, l’allocation des ressources et d’autres indicateurs essentiels pour déterminer si votre projet est sur la voie du succès.
