Les difficultés des projets ne viennent pas seulement d’un manque de méthode. Elles apparaissent souvent quand les finalités, les utilisateurs, les acteurs et les conditions réelles de réussite ne sont pas assez travaillés ensemble.
Il y a une question que je pose souvent en début de formation sur le management de projet. Je demande aux participants combien de projets ils pilotent ou auxquels ils contribuent en ce moment. Les réponses tournent rarement autour de un ou deux. On est plus sur trois, quatre, cinq projets en parallèle — en plus de l’activité habituelle.
Et pendant ce temps, les résultats ne sont pas à la hauteur.
Le Standish Group suit les résultats de projets informatiques depuis 1994 — plus de 50 000 projets analysés. En 2020, leur constat est le suivant : 31 % des projets atteignent leurs objectifs dans les délais et le budget prévu. 50 % sont en difficulté — résultats partiels, retards importants, surcoûts. Et 19 % sont abandonnés ou échouent complètement. Soit 69 % des projets avec des difficultés significatives.
Le rapport 2020 est le dernier publié par le Standish Group. Son arrêt n’est pas dû à une amélioration des chiffres — au contraire, l’organisation a estimé que le concept même de projet, avec son début et sa fin, freinait désormais le développement logiciel et qu’il fallait passer à des modes continus. Une conclusion qui a sa logique propre, et qui n’invalide pas le diagnostic de fond : la dimension humaine reste sous-traitée dans la conduite des projets.
Ce chiffre évolue d’une année à l’autre, et le périmètre informatique a ses spécificités. Mais dans mes interventions depuis vingt ans, dans des contextes très différents — distribution, administration, laboratoires, BTP, ONG — je retrouve les mêmes mécanismes. Pas parce que les personnes manquent de compétences ou de volonté. Mais parce qu’on part souvent du mauvais endroit.
C’est précisément ce que nous travaillons en formation : aider les équipes projet, les contributeurs et les commanditaires à repartir du besoin réel, des acteurs concernés et des conditions concrètes de réussite.
Un projet est réussi quand il produit une solution utile, utilisable et réellement utilisée. Pas seulement quand il est livré.
Cette distinction semble évidente. Elle est pourtant massivement ignorée dans la façon dont les projets sont pilotés.
Déployer un nouveau système d’information, réorganiser un service, mettre en place une nouvelle procédure — ce sont des livrables. Des moyens. Le projet n’est pas réussi le jour où la solution est déployée. Il est réussi — ou pas — dans les semaines et les mois qui suivent, quand on peut constater que les objectifs qui avaient justifié le projet sont réellement atteints.
Cette confusion entre la solution technique et le résultat attendu est l’une des causes les plus fréquentes d’échec. Les équipes projet sont missionnées sur le livrable. Elles font leur travail. Mais si personne ne s’est assuré que la solution serait réellement appropriée, utile dans le contexte réel des utilisateurs, et soutenue dans la durée — le projet technique réussit et le projet organisationnel échoue.
La réussite d’un projet repose sur quatre dimensions. La plupart des organisations n’en travaillent qu’une ou deux.
Le contexte dans lequel le projet s’inscrit, les enjeux pour l’organisation, les objectifs concrets qu’on cherche à atteindre. Pas le projet lui-même — la raison pour laquelle on l’a lancé. Donner du sens au projet, c’est relier en permanence ce qu’on fait à ce pourquoi on le fait.
Les besoins réels des personnes qui vont vivre avec la solution — pas seulement les spécifications fonctionnelles. Il y a presque toujours un écart entre ce que les commanditaires demandent et ce dont les utilisateurs ont vraiment besoin. Coconstruire avec eux n’est pas une bonne pratique optionnelle — c’est une condition de l’appropriation. Une solution conçue en chambre, sans les utilisateurs, sera utilisée de façon dégradée ou contournée.
Le référentiel, le planning, le reporting, la gestion des risques. C’est la dimension que la plupart des organisations travaillent en priorité — parfois en exclusivité. Ce n’est pas là que la réussite se joue, mais c’est là que la plupart des formations se concentrent.
Le commanditaire, le chef de projet, l’équipe, les contributeurs, les managers des membres de l’équipe, les parties prenantes externes. Ce sont les humains qui font réussir le projet — pas les méthodes. Et pourtant, c’est la dimension la moins investie dans la plupart des organisations.
Le piège est classique : on achète un référentiel, on déploie un outil de gestion de projet, on forme les chefs de projet aux livrables et aux jalons — et on est surpris que ça ne suffise pas.
J’ai eu récemment un client qui s’était rendu compte, après coup, qu’il avait acheté un outil de gestion de projet surdimensionné pour ses besoins réels. Trois post-its et Excel auraient fait l’affaire. L’outil n’était pas le problème. Le problème, c’était la façon dont les acteurs travaillaient ensemble.
Après vingt ans d’interventions sur le management de projet dans des contextes très différents, voici ce que j’observe systématiquement dans les projets qui réussissent.
Ils ont un commanditaire actif — pas un sponsor qui signe le lancement et disparaît. Quelqu’un qui prend des décisions difficiles quand elles sont nécessaires, qui arbitre les conflits de priorités, qui donne de la visibilité et de la légitimité au chef de projet.
Ils ont des utilisateurs impliqués dès la conception — pas consultés en fin de parcours pour validation. Les projets qui échouent ont presque toujours un point commun : la solution a été conçue sans les personnes qui devront vivre avec. L’appropriation ne se fabrique pas en fin de projet. Elle se construit tout au long.
Ils ont un chef de projet qui gère les humains autant que les livrables. Tenir un planning, c’est moins souvent un problème de méthode qu’un problème de gestion des engagements, des priorités contradictoires et des relations entre acteurs. Les chefs de projet les plus efficaces ne sont pas nécessairement les meilleurs techniciens du référentiel — ce sont les personnes les plus capables de maintenir la dynamique collective dans les moments difficiles.
Ils font des bilans utiles. Pas des documents de clôture administratifs — de vrais retours d’expérience sur ce qui a fonctionné, ce qui n’a pas fonctionné, et ce qu’on ferait différemment la prochaine fois. C’est là que se construit la vraie compétence projet d’une organisation
Depuis vingt ans, j’entends les mêmes verbatims revenir dans nos formations sur le management de projet. Ils ne sont pas anecdotiques — ils décrivent des difficultés structurelles.
« Je suis sur trois projets en plus de mon activité habituelle. Je ne vois plus le jour. » C’est probablement la situation la plus répandue. Chaque projet a l’impression d’être le seul. Chaque chef de projet pense bénéficier d’une ressource dédiée. La réalité, c’est un contributeur qui arbitre en permanence entre des priorités contradictoires, sans jamais pouvoir s’engager vraiment sur aucune.
« Quand je vois la taille du référentiel projet de notre organisation, j’ai peur qu’on me demande de tout appliquer. » Le référentiel est un moyen. Quand il devient une fin en soi, il génère de l’anxiété et de la résistance. J’ai vu des organisations dont le référentiel prévoit plus de 80 livrables pour des projets qui n’en nécessitent pas le dixième.
« On fait des plannings, mais ils ne sont jamais respectés. » Ce n’est pas un problème de planning — c’est un problème d’engagement, de priorités et de gouvernance. Un planning qu’on ne respecte pas est souvent un planning qu’on n’a pas construit avec les bonnes personnes, ou dans lequel on n’a pas prévu les bons arbitrages.
« Les équipes expérimentées accompagnent les grands projets, mais ne sont pas disponibles pour les petits. » Or c’est souvent en réussissant des petits projets qu’on construit la capacité à réussir les grands. L’expérience ne se transfère pas par osmose — elle se construit dans la pratique accompagnée.
« Dès que le projet est terminé, on passe à autre chose. On fait rarement des retours d’expérience. » C’est la phase de capitalisation — la plus sacrifiée, systématiquement. On la zappe quand le projet s’est bien passé parce qu’on est déjà sur le suivant. On la zappe quand le projet s’est mal passé parce qu’on préfère ne pas y revenir. Résultat : l’expérience s’accumule sans se transformer en compétence.
Le Standish Group constate par exemple un écart spectaculaire entre les petits projets (environ 90 % de succès) et les gros projets pluriannuels (moins de 10 % de succès). Cet écart dit quelque chose de simple : la complexité a un coût, et la décomposer en projets plus petits, plus rapides, mieux dimensionnés produit de meilleurs résultats.
Les méthodes comptent. Un projet sans repères méthodologiques partagés perd du temps et génère des malentendus. Mais des personnes motivées réussiront avec une méthode imparfaite. L’inverse n’est pas vrai.
La gouvernance compte. Un commanditaire trop présent qui interfère à chaque décision est aussi problématique qu’un commanditaire absent qui ne répond plus aux questions critiques. Définir qui décide quoi, à quel moment et selon quels critères, c’est un travail que la plupart des projets ne font pas sérieusement.
Le dimensionnement compte. Il n’existe pas une méthode projet universelle applicable à tous les contextes. Un projet individuel de trois semaines, un projet d’équipe de six mois, et un méga-projet pluriannuel n’ont pas les mêmes besoins de structure, de reporting ou de coordination. Savoir dimensionner — choisir ce qu’on va faire et ce qu’on ne fera pas — est une compétence en soi, rarement enseignée.
La capitalisation compte. Un projet terminé sans retour d’expérience est une occasion manquée. Pas parce que les processus l’exigent — parce que c’est là que se construit vraiment la capacité à réussir les projets suivants. L’expérience brute ne devient compétence que si elle est analysée, mise en mots et partagée.
Et les acteurs comptent plus que tout le reste. Comprendre qui joue quel rôle dans un projet — commanditaire, chef de projet, contributeur, utilisateur, manager de ressources, expert — et faire en sorte que chacun comprenne ce qu’on attend de lui, c’est la condition de base. Évidente en théorie. Rarement mise en œuvre sérieusement en pratique.
Dans nos formations sur le management de projet, les participants travaillent sur leurs projets réels : objectifs flous, contributeurs surchargés, commanditaires peu disponibles, utilisateurs insuffisamment associés, plannings non tenus, méthodes trop lourdes ou trop peu partagées.
Ils repartent avec des repères applicables immédiatement : clarifier la finalité du projet, identifier les acteurs clés, dimensionner la méthode au bon niveau, construire des engagements réalistes, mieux associer les utilisateurs et capitaliser sur les projets terminés
La bonne question n’est pas « comment appliquer une méthode projet ». C’est « qu’est-ce qui empêche réellement les projets de réussir dans mon contexte » ?
Les causes varient selon les organisations. Certaines manquent de repères méthodologiques partagés. D’autres ont trop de méthode et pas assez d’agilité. D’autres ont des acteurs très compétents individuellement qui peinent à travailler ensemble. D’autres encore ont des commanditaires qui ne jouent pas leur rôle.
Un diagnostic honnête de la situation actuelle — ce qui fonctionne déjà, ce qui achoppe, les causes réelles des difficultés — vaut mieux qu’un programme de formation générique sur la gestion de projet. Ce qu’on va mettre en place doit partir du besoin et des acteurs réels, pas du contenu disponible et des méthodes à la mode.
C’est ce que je propose d’explorer dans la formation.
Pour aller plus loin :
Articles à lire aussi :
Vous voulez renforcer la capacité de vos équipes à réussir leurs projets ?
Nous pouvons vous aider à construire une formation adaptée à votre contexte : chefs de projet, contributeurs, commanditaires, managers de ressources ou équipes transverses.
Pourquoi les méthodes de gestion de projet ne suffisent-elles pas à faire réussir les projets ?
Parce que la réussite d’un projet ne se joue pas uniquement sur les livrables et les jalons — elle se joue sur quatre dimensions complémentaires : les finalités, les utilisateurs, les méthodes et les acteurs. La plupart des organisations ne travaillent que la troisième. Des personnes motivées réussiront avec une méthode imparfaite. L’inverse n’est pas vrai.
Qu’est-ce qu’un projet réussi concrètement ?
Un projet qui fournit une solution utile, utilisable et utilisée. Pas un projet livré dans les délais. La solution déployée n’est pas l’objectif — elle est le moyen. Le projet est réussi quand les effets attendus sont réellement atteints dans le quotidien des utilisateurs.
Comment adapter la méthode projet à la taille du projet ?
En partant du projet réel plutôt que d’un référentiel standard. Un projet de trois semaines avec deux personnes n’a pas besoin des mêmes outils qu’un méga-projet pluriannuel. Dimensionner — choisir ce qu’on va faire et ce qu’on ne fera pas — est une compétence en soi. Le mieux est l’ennemi du bien.
Pourquoi les retours d’expérience sont-ils si rarement faits ?
Parce qu’on passe toujours au projet suivant. Quand le projet s’est bien passé, on n’a pas le temps. Quand il s’est mal passé, on préfère ne pas y revenir. Résultat : l’expérience s’accumule sans se transformer en compétence. La capitalisation est la phase la plus sacrifiée — et l’une de celles qui conditionne le plus la capacité à réussir les projets futurs.
Que dit le rapport Standish Group sur la réussite des projets ?
Le Standish Group analyse les résultats de projets informatiques depuis 1994. Dans son rapport 2020 portant sur plus de 40 000 projets, il constate que seulement 31 % des projets atteignent leurs objectifs dans les délais et le budget prévus. 50 % sont en difficulté — résultats partiels, retards importants ou surcoûts. 19 % sont abandonnés ou échouent complètement. Ces chiffres sont propres au secteur informatique mais les mécanismes d’échec qu’ils révèlent se retrouvent dans la plupart des types de projets.
Combien de projets un collaborateur peut-il piloter simultanément ?
Il n’y a pas de réponse universelle, mais les formations terrain révèlent systématiquement le même problème : les contributeurs gèrent trois, quatre, cinq projets en parallèle en plus de leur activité habituelle. Chaque projet a l’impression d’être prioritaire — et personne ne peut s’engager vraiment sur aucun. La règle la plus efficace est simple : réduire le nombre de projets simultanés et s’assurer que les priorités sont arbitrées au niveau de la gouvernance, pas laissées à la charge des individus.
Chaque organisation a ses propres contraintes, ses propres enjeux, son propre terrain.
Un échange de 30 minutes suffit souvent à identifier ce qui serait vraiment utile — et la forme que ça pourrait prendre.
Indiquez votre adresse email pour recevoir la ressource dans votre boite de réception