En gestion de projet, le triangle magique (scope, temps, coût) illustre une réalité incontournable: on ne peut pas modifier une dimension sans affecter les autres. L’approche agile a apporté une réponse pragmatique à ce dilemme en fixant le temps et les ressources pour rendre le périmètre variable. Cette logique est souvent présentée comme une évidence, mais elle mérite un examen critique.
Trois dimensions, un dilemme
Chaque projet est défini par trois dimensions interdépendantes. Le scope (périmètre) détermine ce qui doit être livré. Le temps fixe le calendrier. Le coût couvre les ressources nécessaires. Ajuster l’une de ces dimensions a des répercussions sur les autres: demander plus de fonctionnalités sans changer le budget ni le délai conduit inévitablement à une dégradation de la qualité ou à l’épuisement de l’équipe.
Ce concept, parfois appelé triple contrainte ou iron triangle en anglais, est enseigné dans toutes les formations de gestion de projet. Il constitue le socle de la compréhension des arbitrages projet, quel que soit le référentiel utilisé (PMBOK, PRINCE2, HERMES ou Scrum).
L’approche classique vs l’approche agile
Dans un projet mené en approche prédictive (cascade, cycle en V), les trois dimensions sont théoriquement ajustables. Quand un écart se manifeste, le chef de projet négocie avec le sponsor: réduire le périmètre, repousser le délai ou augmenter les ressources. PRINCE2 encadre cette logique avec un système de tolérances sur chaque dimension.
L’approche agile simplifie ce modèle de décision: l’équipe et la durée des itérations sont fixées, seul le périmètre s’adapte. Le Product Owner priorise le backlog pour que les éléments de plus haute valeur soient traités en premier. Si tout ne peut pas être livré, ce sont les éléments de moindre priorité qui sont reportés ou abandonnés.
Cette simplification a un mérite réel: elle évite les négociations interminables sur les trois dimensions simultanément et force une discipline de priorisation. Dans des contextes d’incertitude élevée, où le périmètre est de toute façon amené à évoluer, fixer le cadre (temps et coût) et laisser le contenu s’adapter est une stratégie souvent plus efficace que de tenter de tout figer dès le départ.
Quand fixer le scope comme variable pose problème
Le problème survient lorsque cette logique est appliquée comme un dogme plutôt qu’un outil de décision. Deux scénarios courants illustrent ses limites.
Premier scénario: l’équipe découvre en cours de sprint qu’une fonctionnalité clé prendra plus de temps que prévu. L’approche agile standard consiste à reporter cette fonctionnalité au sprint suivant ou à la découper. Mais si cette fonctionnalité est celle qui justifie le projet aux yeux du client ou du sponsor, la reporter revient à livrer un produit qui n’atteint pas son objectif fondamental. Dans ce cas, augmenter temporairement la capacité de l’équipe ou accorder un délai supplémentaire serait plus rationnel.
Second scénario: l’équipe termine le travail prévu plus tôt que prévu. L’approche agile encourage alors le Product Owner à ajouter de nouveaux éléments du backlog. Mais du point de vue de l’organisation, réaffecter temporairement cette capacité excédentaire à un autre projet en difficulté pourrait créer davantage de valeur globale. L’orthodoxie agile décourage cette pratique au nom de la stabilité de l’équipe, ce qui peut constituer un gaspillage de ressources à l’échelle de l’organisation.
Une question d’échelle de raisonnement
La tension entre l’approche agile et la rationalité économique tient souvent à une différence d’échelle. Au niveau de l’équipe projet, fixer les ressources et le temps pour varier le scope est logique: cela crée de la stabilité et de la prévisibilité. Au niveau de l’organisation, cette rigidité peut empêcher une allocation optimale des ressources entre les différents projets.
Le PMI a reconnu cette complexité en élargissant le concept de triple contrainte pour y inclure la qualité, les risques et la satisfaction des parties prenantes. Cette vision élargie invite à dépasser le raisonnement triangulaire pour considérer la valeur globale créée par le projet.
Comment arbitrer en pratique?
Plutôt que de s’enfermer dans une doctrine (classique ou agile), le chef de projet gagne à se poser trois questions face à un écart. Premièrement, quelles sont les dimensions réellement flexibles dans ce contexte précis? Un délai réglementaire n’est pas négociable, mais un délai interne peut l’être. Deuxièmement, quelle décision maximise la valeur pour l’organisation, pas seulement pour le projet? Parfois, accepter un dépassement de coût est plus rationnel que de livrer un produit amputé d’une fonctionnalité critique. Troisièmement, les parties prenantes clés partagent-elles la même compréhension des priorités? Un arbitrage sur le scope qui surprend le sponsor est un arbitrage qui a échoué, quelle que soit sa rationalité technique.