Quand un projet déraille, les mêmes phrases reviennent en boucle dans les réunions de post-mortem: budget insuffisant, exigences instables, manque de ressources. Ces explications sont rarement fausses au sens strict, mais elles décrivent des symptômes plutôt que des causes. Le Standish CHAOS Report documente depuis trois décennies que seuls 31% des projets aboutissent conformément aux prévisions initiales, un chiffre qui n’a guère évolué. Si les excuses invoquées étaient les vraies causes, on les aurait résolues depuis longtemps.
Cet article passe en revue cinq excuses récurrentes pour identifier ce qu’elles dissimulent et proposer des leviers d’action concrets.
“Le budget était trop serré”
C’est probablement l’excuse la plus répandue et la mieux acceptée par les comités de pilotage, parce qu’elle déplace la responsabilité vers ceux qui ont alloué les fonds. Dans les faits, le problème se situe rarement du côté de l’enveloppe budgétaire et presque toujours du côté de l’estimation initiale.
La planification fallacieuse (planning fallacy), un biais cognitif documenté par Daniel Kahneman et Amos Tversky dès 1979, explique pourquoi les estimations de coût sont systématiquement optimistes. Lorsqu’une équipe estime un projet, elle raisonne à partir du scénario idéal au lieu de comparer avec des projets similaires déjà réalisés. McKinsey a mesuré des dépassements moyens de 45% sur les grands projets IT, un chiffre qui monte à 80% pour les mégaprojets d’infrastructure.
La réponse ne consiste pas à demander plus de budget, mais à estimer autrement. L’estimation par analogie (reference class forecasting), qui consiste à partir de données réelles de projets passés plutôt que de prévisions théoriques, réduit significativement l’écart. Constituer une réserve pour imprévus dès le cadrage, en la calibrant sur l’historique réel de l’organisation, transforme un budget fragile en budget réaliste.
“Les exigences n’arrêtaient pas de changer”
La volatilité des exigences est un fait de vie en gestion de projet. Les besoins du client évoluent parce que le contexte évolue, parce que la compréhension du problème s’affine, parce que le marché bouge. Ce n’est pas un événement exceptionnel, c’est la norme.
Le vrai problème n’est pas que les exigences changent, mais qu’elles changent sans contrôle. Quand un chef de projet accepte une modification du périmètre (scope) sans évaluer formellement son impact sur le calendrier et le budget, il ne répond pas à un besoin client, il abandonne la gouvernance du projet. Le PMI identifie cinq causes principales de scope creep (dérive du périmètre), dont la première est l’absence de processus formel de gestion des changements.
Un comité de contrôle des changements (change control board), même léger, suffit à rétablir la discipline. Chaque demande fait l’objet d’une évaluation coût-délai et d’une décision explicite: accepter, reporter ou refuser. La clé n’est pas de bloquer les changements, mais de les rendre visibles et de les intégrer en connaissance de cause.
“On n’avait pas assez de ressources”
Cette excuse mérite un examen attentif, car elle masque deux problèmes distincts. Le premier est la sous-déclaration: les équipes tendent à minimiser leurs besoins en ressources lors de la planification, souvent par crainte de paraître déraisonnables ou de voir leur projet refusé. Le projet démarre donc avec un déficit structurel que personne n’a voulu nommer.
Le second problème est la confusion entre quantité et compétence. “On n’avait pas assez de ressources” signifie fréquemment “on n’avait pas les bonnes compétences au bon moment”, ce qui est un problème de planification qualitative et non quantitative. Une matrice RACI (Responsible, Accountable, Consulted, Informed), un outil simple qui cartographie les rôles et responsabilités pour chaque livrable, permet de détecter ces lacunes dès le cadrage plutôt qu’en cours de route.
La planification de capacité réaliste, qui tient compte des autres projets en parallèle et du taux de disponibilité réel des collaborateurs, complète le dispositif. Demander 100% d’un collaborateur qui travaille déjà sur trois autres projets, c’est planifier un échec.
“On n’avait pas le soutien de la direction”
Le manque de sponsorship est rarement un point de départ: c’est un point d’arrivée. Un sponsor de projet ne perd pas son engagement du jour au lendemain, mais progressivement, à mesure que les informations qu’il reçoit deviennent floues, tardives ou excessivement optimistes.
Le PMI estime que la communication insuffisante contribue à l’échec dans 56% des projets. La communication vers le haut est particulièrement critique, car un sponsor qui ne comprend pas l’état réel du projet ne peut ni arbitrer ni protéger l’équipe. Un reporting exécutif régulier, synthétique et honnête, incluant les mauvaises nouvelles, maintient l’engagement bien plus efficacement qu’un appel à l’aide en situation de crise. Escalader un risque quand il est encore gérable relève du professionnalisme; l’escalader quand il est devenu un problème relève du sauvetage.
Les parties prenantes “ne savaient pas ce qu’elles voulaient”
Cette excuse contient une part de vérité, mais elle est mal formulée. Les parties prenantes (stakeholders) ne savent presque jamais avec précision ce qu’elles veulent au début d’un projet, et c’est normal. Leur rôle n’est pas de fournir un cahier des charges parfait dès le premier jour. Le rôle du chef de projet est d’organiser la découverte progressive de ces besoins, par des ateliers de co-construction, des maquettes, des revues intermédiaires et des boucles de validation régulières.
Reprocher aux parties prenantes leur imprécision initiale revient à reprocher à un patient de mal décrire ses symptômes: c’est précisément la raison pour laquelle il consulte un professionnel. Les méthodologies agiles, comme Scrum, intègrent cette réalité par conception en organisant le travail en itérations courtes avec des revues fréquentes. Mais même en approche prédictive, des points de validation réguliers permettent d’affiner la compréhension sans attendre la livraison finale.