Quelles solutions au scope creep

Le scope creep – ou dérive du contenu – est un fléau bien connu des projets informatiques, qui engendre surcoûts et retards importants. Chaque méthode de gestion de projet apporte à ce problème une réponse spécifique.

L’approche traditionnelle cherche à lutter contre la dérive du contenu en ajoutant plus de contrôle, plus de préparation, plus d’implication…

De son côté, l’approche agile considère les modifications de spécification comme un phénomène naturel de maturation du projet.

Dans le tableau ci-dessous, nous avons fait une comparaison entre les solutions de l’approche traditionnelle et celles de l’approche agile en nous basant sur l’article «comment empêcher que la dérive de contenu n’emporte au loin votre projet» qui identifie 5 causes à la dérive du contenu:

  1. Pauvre analyse des besoins
  2. Implication trop tardives des utilisateurs
  3. Sous-estimation de la complexité du projet
  4. Manque de contrôle du changement
  5. Sur-qualité
Causes Approche traditionnelle Approche agile
Pauvre analyse des besoins Passer plus de temps en réflexion et en préparation, meilleures spécifications des besoins, documentation exhaustive… Travailler par petits bouts (incréments), c’est plus simple. De plus, une meilleure compréhension de la part des développeurs et des utilisateurs des besoins réels est facilité par des livraisons et des démos fréquentes.
Implication trop tardives des utilisateurs Plus d’implication, plus de réunions, plus de documentations, développements de scénarios de test, plus de processus de validation… Dans SCRUM, il y a forcément une démo avec les utilisateurs en fin de Sprint (ie tous les 15 jours).
Sous-estimation de la complexité du projet Ajouter des provisions pour aléas, ajouter de la marge dans le planning, prévoir des ressources supplémentaires… Travailler par petits incréments réduit la complexité et favorise la recherche de solutions simples.
Manque de contrôle du changement Plus de processus (formulaire, validation, registre, analyse d’impact) Pendant une itération (Sprint) aucun changement n’est accepté, pour le reste on en discute pendant le planning de la prochaine itération avec le représentant des utilisateurs et du sponsor.
Sur-qualité Plus de management et de communication sur les enjeux L’équipe s’engage à livrer un produit fini tous les 15 jours (pas le temps de traîner). Chaque membre de l’équipe annonce ce qu’il va faire dans la journée (SCRUM) ce qui est aussi une forme d’engagement.

Il n’y a pas d’approche meilleure que l’autre, mais simplement des objectifs différents liés à des contraintes – souvent financières – différentes. L’approche traditionnelle est plus adaptée dans le cadre d’un engagement de résultat (mode forfait) tandis que l’approche Agile sera plus adaptée pour optimiser la valeur business avec un engagement limité de moyens. (Ce dernier point est souvent débattu.)

Mais la vraie question derrière le problème de la dérive du contenu est: Comment définit-on la réussite d’un projet ?

Est-ce le fait d’avoir respecté un engagement de délais et de coûts défini au début du projet ou d’avoir un client et des utilisateurs satisfaits à la fin du projet ? Ce n’est pas la même chose…

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *