La plupart des clients veulent à juste titre, savoir quel sera leur ROI s’il décidait d’investir dans le déploiement des pratiques agiles sur leur activité projet, de maintenance ou de réalisation de nouvelles applications.

Afin de pouvoir apporter des éléments concrets à cette problématique incontournable, je propose de m’appuyer sur un cas concret décrit principalement par :

• Un contexte client;
• Des budgets;
• Des natures de projet diverses;
• Une organisation spécifique;
• Une demande plutôt légitime.

II - Problématique du client

Contexte client :

Un client possède un département informatique représentant 100 projets et 700 personnes dont environ 400 intervenants extérieur.

Le middle management est réfractaire à l’agilité et doit donc être convaincu par la Direction qui souhaite déployer les pratiques agiles et qui compte sur un fournisseur pour l’aider via une présentation officielle mettant en avant le ROI d’une telle démarche.

Budget du client :

Le budget annuel des projets (maintenance comprise) représente environ 20 M€.

Ce client peut dépenser 1 M€ pour déployer l’agilité sur son périmètre projet.

Natures de projet :

Les projets réalisés dans le département informatique du client se répartissent aujourd’hui de la façon suivante :

• Projets de maintenance : 40% du budget;
• Projet de réalisation :       60% du budget.

Organisation spécifique :

En fin d’année d’Octobre à Décembre, le client travaille sur les budgets de l’année suivante en identifiant ses nouveaux projets.

En début d’année suivante, le client déstaffe en masse les équipes projet de Janvier à Février (2 mois) durant lesquels ses équipes spécifient les nouveaux projets.

Début Mars, le client démarre les nouveaux projets et staffe à nouveau ses équipes avec de nouveaux intervenants extérieurs.

Demande du client :

Le client  souhaite connaître l’ordre de grandeur du ROI lié à l’adoption de pratiques projets agiles.

Ce ROI est évalué par le client en nombre de projets qu’il peut réaliser avec un même budget annuel. Il souhaite par conséquent augmenter le nombre de projets réalisés en une année grâce à l’agilité et en parallèle, diminuer la part prise par les projets de maintenance.

III – Analyse des données client

Aucune information détaillée sur la taille actuelle des 100 projets réalisés annuellement n’est connue.

Aucune information détaillée sur la nature des activités de maintenance (corrective ou évolutive) n’est connue, ni sur la taille des “defect backlogs”.

Aucune information détaillée concernant les frais de structure et d’encadrement n’est connue.

IV – Hypothèses retenues

Les hypothèses retenues proviennent de statistiques ou du contexte client devant être discutées avec le client à l’occasion d’interviews ou de réunions supplémentaires.

IV.I – Statistiques

Taux de succès des projets agiles / projets traditionnels (www.agilemodeling.com de Scott W. Ambler)

• Taux de succès des projets traditionnels : 50%
• Taux de succès des projets agiles : 65%

 Les tailles moyennes des équipes agiles se répartissent de la manière suivante :

78% des équipes agiles ont une taille d’équipe de 5 à 15 personnes. Cette taille de projet constitue la taille optimale pour l’agilité, évitant des organisations de management plus lourde et donc moins agiles pour des équipes importantes, et des équipes trop petites (moins de 5 personnes) pour conserver des pratiques agiles efficaces.

Dans 65% des cas environ, la satisfaction des clients a été améliorée par la mise en œuvre de l’agilité sur les projets. Il faut dire que statistiquement, il est courant de constater à posteriori que plus de 40% des fonctions livrées n’ont quasiment jamais été utilisées par les opérationnels. Enfin 56% des problèmes rencontrés en cours de projet proviennent des besoins exprimés.

   « The state of agile development » Juin 2010, FrenchSUG : Analyse des méthodes agiles – 2009

Dans plus de 74% des cas, la productivité des équipes est améliorée par la mise en œuvre de pratiques agiles.

« The state of agile development » Juin 2010, FrenchSUG : Analyse des méthodes agiles – 2009

Dans plus de 68% des cas, la qualité des logiciels produits est améliorée. 

« The state of agile development » Juin 2010, FrenchSUG : Analyse des méthodes agiles – 2009

IV.II – Hypothèses client

• Taille actuelle des projets : nous pouvons par exemple imaginer que les petits projets (moins de 5 personnes) sont en plus grand nombre que les gros projets (supérieure à 15  personnes) et que 60% des projets ont une taille comprise entre 5 et 15 personnes. Soit une hypothèse de distribution théorique de 15% de gros projets, 60% de projet moyens et 25% de petits projets.
• Les 100 projets réalisés sont considérés comme étant réalisés hors maintenance, c’est à dire qu’il n’inclut pas les projets de maintenance.
• La nature des activités de maintenance est inconnue pour le moment. S’agit-il de maintenance corrective uniquement (correction d’anomalies) ou de maintenance corrective et évolutive avec des nouvelles fonctions à réaliser en plus des anomalies à corriger ? Soit une hypothèse de distribution théorique entre correction et évolution de 30% de correction et 70% d’évolution.
• Chaque année, 400 extérieurs interviennent mais sur 10 mois au lieu de 12, une fois les spécifications rédigées. Le changement de ressources lié au déstaffing et au restaffing des intervenants extérieurs induit une montée en compétence systématique et coûteuse dont le budget peut être estimé au alentour de 5%. 
• Pour un même budget annuel, si les intervenants extérieurs travaillaient 12 mois de l’année au lieu de 10, le nombre d’intervenants diminueraient de 15% environ. Cela induirait une diminution des frais d’infrastructure et d’encadrement en proportion.
• Les coûts d’infrastructure sont estimés à 200 € par personne et par mois pour l’estimation de l’économie engendrée par une baisse du nombre moyen d’intervenants extérieurs sur l’année.

V – Axes de réflexion sur le ROI

1)  Concernant la taille des équipes

L’agilité étant optimale sur des projets de taille moyenne (entre 5 et 15 personnes), un axe d’optimisation du ROI consisterait à :

• Diminuer la taille des gros projets en créant des équipes indépendantes de taille plus raisonnable;
• Mutualiser les petits projets en créant des équipes multi projets par technologie ou par métier.
• La réorganisation des projets via la réduction de taille des gros projets et la mutualisation des petits projets conduirait à une meilleure utilisation des pratiques agiles et donc à une meilleure productivité et qualité sur l’ensemble des projets. Le nombre global de projets resterait quasiment inchangé.

2) Concernant la nature de la maintenance

Sur les activités de correction, un axe d’optimisation du ROI consisterait à :

• Augmenter la qualité des produits en maintenance corrective en corrigeant prioritairement les anomalies jusqu’à réduire à 10% la charge nécessaire sur le long terme à la correction des anomalies par rapport à la charge globale de production (en 2012). L’effet positif se fera sentir en 2013 avec une augmentation de la capacité de production et donc une diminution de la part de maintenance corrective de 30% à 10% et une augmentation de la part de maintenance évolutive de 70% à 90%.
• Assurer la qualité de la maintenance évolutive permettant à la part consacrée aux corrections d’anomalie de ne jamais dépasser 10%.

Sur la base des hypothèses prises (30% de maintenance corrective à T0), on peut raisonnablement planifier une baisse de la maintenance corrective de 10% par an sur deux ans, à l’avantage de la maintenance évolutive. Cela se traduirait par une augmentation de la maintenance évolutive de 10% par an sur deux ans.

3) Concernant le succès des projets

Les statistiques démontrent que le taux de succès des projets agiles est au minimum de 15% par rapport aux projets traditionnels. Ce gain est obtenu par la diminution des coûts de non qualité et par l’augmentation de la productivité des équipes.

L’augmentation du taux de succès des projets d’environ 15% une fois les pratiques agiles déployées et maîtrisées se traduirait donc par une économie substantielle de budget. Ce budget peut être évalué par exemple en considérant un dépassement moyen en effort de 20% pour les projets en échec. Si les projets représentent 60% du budget, que les projets qui étaient en échec représentent 15% et que cet échec représente en moyenne 20% de dépassement, une économie de 1,8% serait possible (60% x 15% x 20%).

4) Amélioration de la satisfaction client

L’amélioration de la satisfaction client se traduira par la diminution du taux des fonctionnalités livrées mais jamais utilisées car remplacées par des fonctionnalités à plus haute valeur ajoutée. Cela survient grâce aux feedbacks réguliers et fréquents du métier lors des démonstrations de fin d’itération, mais également grâce à la capacité de l’équipe à être force de proposition car plus et mieux impliquée sur le produit. Il paraît donc raisonnable que le taux de non utilisation passe de 40% à 20% environ. Le budget récupéré correspondant devrait permettre soit d’améliorer la valeur du produit livré (15%), soit de le réinvestir sur de nouveaux projets (5%) et inciter le métier à confier plus de demandes au département informatique. Une économie de budget d’environ 5% peut probablement être atteinte.

5) Amélioration de la qualité logiciel et augmentation de la productivité des équipes

L’amélioration de la qualité des logiciels réalisés en agile se traduit par une baisse de la capacité de production consacrée à la correction des anomalies en cours de projet, renforçant encore l’augmentation de productivité des équipes agiles obtenues par la dynamique et le rythme projet.

Cette augmentation de productivité se traduit par une diminution des budgets nécessaires à la réalisation d’un certain périmètre de fonctionnalités ou par une augmentation de la taille logicielle livrée pour un certain budget.

Une augmentation de productivité de 10% à 20% par rapport à la productivité sur un projet traditionnel est courante et peut varier selon les cas. Elle est liée principalement à :

• Une meilleure motivation et responsabilisation des équipes ;
• Un outillage compatible des pratiques agiles qui vise à automatiser bon nombre d’activités (Intégration, vérifications, tests, déploiement…) ;
• Des estimations et une planification plus précises et fréquentes ;
• Un suivi plus rigoureux basé sur les fonctionnalités réalisées et livrées pas à pas ;
• Une amélioration continue via les rétrospectives ;
• Un meilleur travail en équipe et avec les différentes parties prenantes (principalement le« Product owner », et les « end users ») ;
• Une qualité logicielle évitant de dépenser beaucoup d’effort à corriger des anomalies.

6) Réorganisation du travail du département informatique :

Le déstaffing des intervenants extérieurs deux mois de l’année pourrait être évité par la priorisation des projets et le lissage des activités de spécifications tout au long de l’année. Cela peut être réalisé avec la constitution de roadmap produit et de « product backlog » au fil de l’eau chaque fois que de nouveaux besoins émergent notamment à l’occasion des démonstrations et des livraisons de releases.

Il paraît raisonnable de considérer une économie de montée en compétence de 5% sur les 400/700 ième du budget, à condition de considérer que le coût des intervenants internes est identique à celui des intervenants externes (ce qui est forcément faux mais simplifie le calcul). Cela correspond à une économie de budget de 2,5%.

Il faut ajouter à cela, une réduction des coûts globaux d’infrastructure d’environ 15% (400p sur 10 mois = 4000 p.m => 4000 p.m./12 = 333 p => Ecart de 67p/400 = -16%).

Si on considère que les coûts d’infrastructure et d’encadrement représentent 200€ par mois et par personne, la réduction des coûts d’infrastructure d’environ 15% représenterait 15% de 200€ * 12 * 400p = 144 000 € / ans. Cette économie représenterait 0,7% du budget global qui est de 20 M d’Euros.

VI – Conclusion

Activités de maintenance :

L’impact de la diminution progressive de la part de maintenance corrective (-10% par an sur deux ans) liée à l’application des pratiques agiles se traduirait sur le budget constant du département informatique par :

• Une diminution de la part de maintenance globale de 40% à 32% ;
• Une augmentation du nombre de projets réalisés de 13,3%.

Activités projet :

L’impact de l’agilité sur les projets est positif et peut être quantifié dans le temps (entre 2012 et 2014) de la façon suivante :

• Augmentation du taux de succès des projets de 15%;
• Diminution du taux de fonctionnalités livrées inutilisées de 20%;
• Augmentation de la productivité des projets de 10% ;
• Diminution du nombre d’intervenants extérieurs nécessaires de 15%.

En termes d’économies budgétaire, le tableau suivant décrit entre 2012 et 2014 les économies correspondantes :

Economie globale pressentie :

Les économies pressenties globalement se répartissent de la façon suivante :

Indicateurs projet :

Ces économies se concrétiser par une augmentation du nombre de projets pouvant être réalisée de la façon suivante :

Economies et indicateurs estimés en mode dégradée :

Si le périmètre de la maintenance n’était pas revu à la baisse et si l’organisation du travail restait inchangée (10 mois travaillés pour les intervenants externes), les économies réalisables par le seul jeu de l’agilité sur le périmètre projet seraient décrites de la façon suivante :

Les économies pressenties globalement se répartiraient de la façon suivante :

L’augmentation du nombre de projets se réaliserait de la façon suivante :

Retour sur investissement (ROI) :

Si nous partons de l’hypothèse que le client investit 1 M Euros en 2012 et en 2013, puis 500 K Euros en 2014 pour passer intégralement sa structure à l’agilité, le calcul de ROI nous donnerait :

L’investissement serait donc rentabilisé au bout de la seconde année, c’est-à-dire fin 2013.

En mode dégradé, le calcul de ROI nous donnerait :

L’investissement serait donc rentabilisé au bout de la troisième année, c’est-à-dire en 2014.