Le coût caché d'un projet à prix fixe

Nous nous méfions des estimations fixes pour le logiciel, surtout pour du nouveau. Liez un projet à un seul chiffre au départ et vous rendez le changement coûteux, précisément quand la liberté de corriger le cap compte le plus.

Le changement est la norme

Sur de vrais projets, les besoins évoluent à mesure que chacun apprend. Sous un périmètre fixe, chaque changement doit être ré-estimé et repoussé à une phase ultérieure ; la livraison devient quelques gros jalons espacés de plusieurs mois au lieu d'un flux régulier de logiciel qui fonctionne.

Livrer souvent vaut mieux qu'une grande révélation

Livrer par petits incréments fait que le retour arrive tôt, tant qu'il est encore peu coûteux d'agir, et le travail reste visiblement sur les rails. Une estimation fixe pousse à l'inverse : tout retenir, tout réconcilier à la fin, et espérer que ça tienne encore.

À quoi ressemble une estimation honnête

Nous estimons toujours, nous refusons seulement de faire semblant. Une estimation honnête est une fourchette avec ses hypothèses écrites : ce que nous croyons simple, ce que nous soupçonnons épineux, et quelles inconnues feront bouger le chiffre. À mesure que le projet nous apprend, la fourchette se resserre au grand jour, au lieu qu'un chiffre fixe absorbe le risque en marge cachée.

Un prix au fil de l'eau

Un prix fixe donne un sentiment de contrôle du budget, mais il plafonne le projet et coûte souvent plus au final, car le risque doit être provisionné. Nous préférons chiffrer au fur et à mesure, vous laisser décider de la suite, et privilégier la réponse au changement plutôt que le suivi d'un plan.