Les référentiels de gestion de projet décrivent le chef de projet comme un planificateur, un coordinateur, un communicateur. Ils disent moins souvent qu’il devrait aussi être un analyste. Pourtant, les projets qui échouent ne manquent généralement pas de plans ni de processus: ils manquent d’analyse. Analyse des vrais besoins derrière les demandes, analyse des données derrière les impressions, analyse des causes derrière les symptômes.
La business analysis (analyse métier), discipline voisine de la gestion de projet, a formalisé des habitudes intellectuelles qui répondent précisément à ces manques. Sans devenir business analyst, le chef de projet peut s’approprier une posture analytique qui renforce chaque phase de son travail.
Le piège du chef de projet exécutant
Un chef de projet peut maîtriser parfaitement les outils de planification, produire des diagrammes de Gantt impeccables et tenir des comités de pilotage irréprochables, sans pour autant garantir le succès du projet. Si le projet répond au mauvais problème, l’excellence d’exécution ne sauve rien.
Le PMBOK 7e édition du PMI a intégré le “Business Acumen” dans son Talent Triangle, reconnaissant que la compétence technique de gestion ne suffit plus. Le chef de projet doit comprendre le contexte métier dans lequel son projet s’inscrit, exactement comme le fait un business analyst quand il analyse un domaine avant de documenter des exigences.
Trois habitudes analytiques à cultiver
Distinguer le besoin de la demande
Quand un directeur commercial demande “un nouveau CRM”, le business analyst ne note pas “nouveau CRM” dans son cahier des charges. Il explore ce qui motive la demande: des rapports de vente peu fiables? Un processus de suivi client trop manuel? Une perte de visibilité sur le pipeline commercial?
Le chef de projet qui adopte cette habitude modifie fondamentalement son rapport au cadrage. Au lieu d’accepter le scope tel qu’il est formulé, il cherche à comprendre le problème sous-jacent. L’IIBA, dans son référentiel BABOK (Business Analysis Body of Knowledge), appelle cela “comprendre le contexte du changement”, et cette distinction entre le besoin réel et la solution présupposée évite des mois de travail sur une solution inadaptée.
Chiffrer systématiquement
“Les utilisateurs sont mécontents” est un constat. “72% des utilisateurs interrogés jugent le temps de traitement inacceptable et 35% ont développé des contournements manuels” est une base de travail. L’habitude de quantification transforme des opinions en faits exploitables.
En gestion de projet, cette rigueur s’applique au-delà des indicateurs classiques de coût et délai. Combien de demandes de changement ont été soumises ce mois-ci? Quel pourcentage des risques identifiés s’est matérialisé? Quelle est la durée moyenne entre l’identification d’un problème et sa résolution? Ces données de pilotage permettent de repérer des tendances avant qu’elles ne deviennent des crises et de fonder les décisions sur des éléments tangibles plutôt que sur des intuitions.
Remonter à la cause racine
Face à un retard de livraison, la réaction instinctive est d’ajouter des ressources ou de revoir le planning. Le réflexe analytique est différent: pourquoi ce livrable est-il en retard? La technique des 5 Pourquoi, empruntée au lean manufacturing et largement utilisée en business analysis, consiste à enchaîner les questions causales jusqu’à identifier le facteur déclencheur réel.
Un livrable est en retard. Pourquoi? Parce que les spécifications ont changé en cours de développement. Pourquoi? Parce que les exigences initiales étaient ambiguës. Pourquoi? Parce que l’atelier de recueil n’incluait pas les utilisateurs finaux. La cause racine n’est pas un problème de planning mais un problème de processus de cadrage, et c’est ce processus qu’il faut corriger pour éviter la récurrence.
La posture qui change la dynamique
Au-delà des techniques, c’est une posture qui distingue le chef de projet analytique. Cette posture repose sur trois attitudes complémentaires.
La première est le questionnement systématique: ne pas prendre les informations au premier degré, vérifier les hypothèses et demander des preuves plutôt que des affirmations. Cette attitude n’est pas de la méfiance mais de la rigueur intellectuelle appliquée au quotidien du projet.
La deuxième est la synthèse sans appauvrissement. Condenser une semaine de travail en un rapport d’une page sans perdre les informations qui appellent une décision est un exercice que le business analyst pratique quotidiennement. Le piège est double: trop de détails noie le décideur, trop peu masque les signaux d’alerte.
La troisième est l’assertivité calibrée. Le chef de projet doit parfois dire non à un sponsor, contester une estimation ou signaler qu’un risque n’est pas traité. Le faire de manière agressive crée du conflit, le faire de manière passive laisse le problème s’aggraver. L’assertivité juste consiste à exprimer une position factuelle, appuyée par des données, sans agressivité ni soumission.
Quand l’analyse devient un réflexe quotidien
Les organisations performantes en gestion de projet sont souvent celles où la frontière entre le rôle de chef de projet et celui d’analyste est perméable. Le chef de projet qui sait conduire un atelier de recueil d’exigences, analyser un processus métier ou structurer une analyse d’impact ne remplace pas le business analyst: il devient un interlocuteur plus efficace pour l’ensemble de ses parties prenantes et un meilleur garant de la pertinence de ce que son projet livre.