Un constat revient dans la plupart des bilans de projet: les livrables correspondent au cahier des charges, mais les utilisateurs ne sont pas satisfaits. L’explication tient rarement à un défaut d’exécution. Elle tient à la manière dont les besoins ont été formulés dès le départ.
Le biais de la solution implicite
Quand une partie prenante exprime un besoin, elle le formule presque toujours sous forme de solution. « Il nous faut un tableau de bord » est une solution. « Il nous faut une réunion hebdomadaire de suivi » est une solution. Le besoin réel, celui qui justifie ces demandes, reste implicite: évaluer rapidement si le projet dérive, anticiper les problèmes avant qu’ils ne deviennent critiques, ou disposer d’arguments factuels pour arbitrer les priorités.
Ce mécanisme n’a rien de surprenant. Les parties prenantes ne sont pas des analystes métier; elles raisonnent avec les outils qu’elles connaissent et proposent ce qui leur semble logique. Le problème apparaît quand le chef de projet prend ces solutions implicites pour des exigences et les inscrit telles quelles dans le périmètre.
Ce que le JTBD révèle
Le framework Jobs to Be Done (JTBD), formalisé par Clayton Christensen à Harvard, propose un changement de perspective significatif. Au lieu de demander aux gens ce qu’ils veulent, il s’agit de comprendre le travail (le « job ») qu’ils tentent d’accomplir.
L’exemple canonique est celui du milkshake McDonald’s. En observant les acheteurs matinaux, les chercheurs ont découvert que le milkshake n’était pas en concurrence avec d’autres desserts mais avec les bagels et les bananes: le « job » était d’occuper un trajet en voiture et de couper la faim jusqu’à midi. En reformulant le produit autour de ce job, les ventes ont été multipliées par sept.
Transposé à la gestion de projet, le JTBD invite à distinguer trois couches dans chaque demande. Le Christensen Institute les décrit comme le job fonctionnel (la tâche concrète), le job émotionnel (le ressenti recherché) et le job social (l’image projetée auprès des autres).
L’angle mort des méthodes classiques
Les méthodes classiques de collecte des exigences (entretiens structurés, ateliers de spécification, questionnaires) excellent pour capturer le job fonctionnel. Elles sont en revanche quasi aveugles aux dimensions émotionnelles et sociales, qui influencent pourtant fortement la satisfaction des parties prenantes.
Un reporting financier mensuel peut remplir parfaitement son job fonctionnel (fournir les données de coûts) tout en échouant sur le job émotionnel si son format technique génère de l’anxiété chez un sponsor non financier. De même, un outil de planification peut être techniquement irréprochable mais rater son job social si les parties prenantes ne peuvent pas l’utiliser pour communiquer simplement l’état du projet à leur propre hiérarchie.
Des exigences aux outcomes
Tony Ulwick a prolongé le travail de Christensen en développant le concept de « desired outcome statements », des énoncés de besoins qui décrivent un résultat mesurable sans prescrire de solution. La structure est volontairement contrainte: chaque énoncé commence par un verbe d’action, porte sur une métrique observable et ne contient aucune référence à un outil ou un livrable.
Comparons deux formulations pour le même besoin. L’exigence traditionnelle: « Mettre en place un comité de pilotage mensuel avec un reporting standardisé. » L’outcome JTBD: « Réduire le temps nécessaire pour évaluer la santé globale du projet et prendre des décisions correctives. » La seconde formulation ne préjuge pas de la solution: le résultat pourrait être atteint par un tableau de bord visuel, un indicateur de type RAG (rouge-ambre-vert) envoyé par courriel ou une réunion de quinze minutes, selon le contexte.
L’intérêt pour le cadrage de projet
En phase de cadrage, cette approche modifie la nature même de l’analyse des parties prenantes. Au lieu de collecter des listes de fonctionnalités souhaitées, le chef de projet cartographie les jobs que chaque partie prenante tente d’accomplir, puis identifie ceux qui sont mal servis, c’est-à-dire ceux où l’écart entre l’importance du job et la satisfaction actuelle est le plus grand.
Cette priorisation par l’insatisfaction est plus robuste qu’une priorisation par le volume des demandes, car elle distingue ce qui est réellement problématique de ce qui est simplement visible. Un besoin exprimé avec insistance par une partie prenante vocale n’est pas nécessairement le besoin dont la résolution apportera le plus de valeur au projet.
Au-delà de l’intuition
Les chefs de projet expérimentés pratiquent souvent une forme intuitive du JTBD lorsqu’ils reformulent les demandes ou creusent le « pourquoi » derrière le « quoi ». Le framework ne fait que structurer cette intuition en lui donnant un vocabulaire (jobs, outcomes, dimensions) et un processus reproductible.
Pour les projets à forte incertitude ou impliquant de nombreuses parties prenantes aux intérêts divergents, cette structuration fait la différence entre un cadrage qui capture les vrais besoins et un cadrage qui empile des exigences dont personne ne pourra vérifier qu’elles répondent au problème initial.