Un ERP livré à temps, des utilisateurs absents
Un projet de déploiement ERP respecte son budget et ses délais. L’équipe est satisfaite, le comité de pilotage valide la livraison. Six mois plus tard, les équipes terrain contournent le système avec des tableurs parallèles, les données sont incohérentes et le retour sur investissement reste introuvable. Que s’est-il passé?
Ce scénario est banal dans la gestion de projet, tous secteurs confondus. Il illustre un angle mort que le product management a appris à traiter depuis longtemps: la confusion entre output et outcome. L’output désigne ce que le projet produit concrètement, le livrable tangible. L’outcome désigne l’effet que ce livrable génère chez ses destinataires, le changement de comportement, l’amélioration mesurable, la valeur effectivement créée. Un projet peut atteindre tous ses outputs sans produire le moindre outcome.
Pourquoi la gestion de projet classique mesure mal la valeur
Les référentiels traditionnels de gestion de projet structurent le suivi autour de trois axes: le périmètre (scope), les délais et le coût. Ce triptyque, souvent représenté sous forme de triangle des contraintes, fournit un cadre clair pour mesurer la conformité du projet au plan. Le problème est que la conformité au plan ne garantit pas la création de valeur.
Le PMBOK 7e édition a reconnu cette limite en introduisant le concept de Value Delivery System, qui place les résultats au centre de la réflexion plutôt que les livrables. Ce virage, opéré en 2021, officialise un constat que les praticiens du product management formulent depuis des années: le succès se mesure dans l’adoption et l’impact, pas dans la livraison elle-même.
Pour un chef de projet, cette grille de lecture ne remplace pas le suivi classique mais le complète. Le plan de projet reste nécessaire pour coordonner les activités et maîtriser les ressources. En revanche, se limiter à des indicateurs de livraison crée un risque réel: celui de piloter le projet comme une chaîne de production plutôt que comme un vecteur de changement.
La “feature factory”, un syndrome à reconnaître
Le product management a donné un nom à cette dérive: la feature factory. L’expression désigne une équipe qui produit des fonctionnalités à un rythme soutenu sans jamais vérifier si ces fonctionnalités résolvent un problème réel. La productivité est élevée, le backlog se vide, les graphiques d’avancement sont au vert, mais la satisfaction des utilisateurs stagne ou régresse.
Le chef de projet fait face à un risque équivalent quand il concentre toute son énergie sur la livraison des lots prévus dans le plan sans s’interroger sur leur pertinence au fil du temps. Un projet de longue durée, typiquement six mois ou plus, évolue dans un contexte mouvant: les priorités de l’organisation changent, la compréhension du besoin s’affine, de nouvelles contraintes apparaissent. Un livrable parfaitement conforme au cahier des charges initial peut se révéler obsolète le jour de sa mise en production.
Le product management répond à ce risque par une pratique appelée continuous discovery (découverte continue), qui consiste à maintenir un contact régulier avec les utilisateurs tout au long du développement. L’objectif n’est pas de remettre en cause le projet en permanence, mais de vérifier que les hypothèses de départ restent valides et d’ajuster les priorités en conséquence.
Comment intégrer la logique outcome dans un projet?
La transition d’une logique output vers une logique outcome ne requiert pas de changer de méthodologie. Elle implique d’ajouter une dimension au pilotage existant, avec quelques pratiques concrètes.
La première consiste à définir des indicateurs de succès qui dépassent la livraison. Pour chaque livrable majeur du projet, la question “comment saurons-nous que cela fonctionne?” devrait être posée dès la phase de cadrage. Si le projet déploie un nouvel outil de reporting, l’indicateur de livraison est “l’outil est accessible à tous les utilisateurs”. L’indicateur d’outcome pourrait être “80% des managers l’utilisent pour préparer leur revue mensuelle dans les trois mois suivant le déploiement”.
La deuxième pratique est de maintenir un canal ouvert avec les bénéficiaires finaux. Le cahier des charges capture le besoin tel qu’il est compris à un instant donné, et cette compréhension est par nature incomplète. Un entretien trimestriel avec trois ou quatre utilisateurs clés suffit à détecter les écarts entre ce qui est prévu et ce qui est réellement attendu, avant que ces écarts ne deviennent des problèmes à la livraison.
La troisième pratique, peut-être la plus difficile, est d’accepter que certains livrables prévus au plan ne méritent plus d’être réalisés. Le product manager apprend à dire non pour protéger la cohérence de sa vision produit. Le chef de projet peut adopter le même réflexe face au scope creep (dérive du périmètre), non pas en invoquant la clause contractuelle, mais en démontrant que la demande ne contribue pas à l’outcome visé.
Un changement de posture plus qu’un changement de méthode
Cette évolution, qui reflète un mouvement de fond dans la profession, se traduit par un investissement massif du PMI dans la convergence entre project et product management. Les compétences du chef de projet s’élargissent: il ne suffit plus de livrer dans les règles de l’art, il faut aussi s’assurer que ce qui est livré produit l’effet attendu. Pour un praticien en début de carrière, intégrer cette double lecture dès le départ constitue un avantage significatif par rapport à ceux qui resteraient focalisés uniquement sur la conformité au plan.