Courbe du coût du changement

Pourquoi le coût d'un changement augmente-t-il au fil du projet ?

La raison tient à la quantité de travail qui repose sur une décision. Tant qu'une exigence ne figure que dans le concept, la modifier ne touche qu'un document. Si elle figure dans la conception, elle touche la conception et tout ce qui en découle. Si elle est réalisée et réceptionnée, s'y ajoutent la reprise, une nouvelle vérification, la documentation et la communication. La courbe ne monte donc pas de façon linéaire, mais à peu près exponentielle.

D'où vient la courbe, et reste-t-elle valable ?

Les chiffres remontent à Barry Boehm, qui les a tirés de données de projets dans « Software Engineering Economics » en 1981. Pour les projets classiques à exécution coûteuse, par exemple dans le bâtiment, l'ingénierie industrielle ou l'événementiel, la relation reste valable. Ce qui est modifié sur le chantier coûte plusieurs fois ce que la modification aurait coûté en phase d'études.

Dans le développement logiciel, la courbe s'est nettement aplatie. Les tests automatisés, l'intégration continue et les petites livraisons réduisent fortement le coût d'un changement tardif. Kent Beck en a tiré la thèse inverse : si la courbe est plate, se fixer tôt ne paie plus, car on peut alors décider au moment où l'on en sait le plus.

La forme que prend la courbe dépend donc du projet, pas de la méthode. Elle monte fortement là où l'exécution est coûteuse et où les résultats s'appuient les uns sur les autres, comme dans le bâtiment ou lors de migrations. Elle reste plate là où les corrections sont bon marché et vérifiables automatiquement. La pente détermine à quelle phase du cycle de vie du projet une décision garde sa valeur.

Que change la courbe pour la planification du projet ?

• Clarifier les exigences tôt : un énoncé des travaux écrit et une revue avant chaque passage de phase déplacent la clarification là où elle coûte peu.
• Clore les phases par des jalons : dans le modèle en cascade, chaque jalon marque une décision sur laquelle repose la phase suivante.
• Chiffrer les changements tardifs : chaque changement déplace le coût, le délai ou le périmètre au sein de la triple contrainte. Chiffrez cet effet avant de l'accepter.

Exemple : pendant la construction d'un immeuble de bureaux, le maître d'ouvrage veut déplacer une cloison. En phase d'études, l'architecte modifie un plan. Si la cloison est déjà montée, s'ajoutent la démolition, une nouvelle cloison, l'électricité, l'enduit et la peinture, plus une nouvelle date de réception.

Comment garder une trace des décisions dans Merlin Project ?

Pour exploiter la courbe, vous devez voir plus tard ce qui était planifié au moment d'une décision. Merlin Project enregistre tout l'historique du projet dans chaque document et travaille avec une ligne de base dynamique. Vous n'avez pas besoin d'enregistrer une ligne de base manuellement.

1. Placez un jalon à la fin de chaque phase avec Insertion › Jalon (Alt+Cmd+M), par exemple « Conception approuvée ».
2. Après un changement, ouvrez Fichier › Réglages du projet (Cmd+;) et saisissez la date de l'approbation dans le champ Date de référence.
3. Tous les champs Planifié affichent alors les valeurs de ce jour. Dans le diagramme de Gantt, elles apparaissent sous forme de barres de référence grises à côté des barres actuelles.
4. Les vues Comparaison plan/réel (temps) et Comparaison plan/réel (coût) présentent les écarts sous forme de tableau.

Vous voyez ainsi ce qu'un changement tardif a décalé en délais et en coûts. La ligne de base dynamique et les vues de comparaison font partie de Merlin Project uniquement, pas de Merlin Project Express.