EVM pour les Projets IT et Logiciels
Appliquer la Gestion de la Valeur Acquise (GVA) aux projets informatiques et logiciels est plus complexe que pour la construction. Le travail logiciel est abstrait, les exigences peuvent évoluer, et mesurer le « taux d'avancement » d'une fonctionnalité est intrinsèquement subjectif. Néanmoins, avec les bonnes adaptations, l'EVM apporte une valeur considérable.
Le défi fondamental : mesurer la Valeur Acquise en logiciel
1. Story Points (EVM Agile)
Dans les environnements Scrum ou Kanban, les équipes estiment leur travail en story points. L'EVM peut s'y greffer :
- BAC = Total story points × coût moyen par story point
- VP = Story points planifiés jusqu'au sprint actuel
- VA = Story points réellement complétés × coût par story point
- CR = Coûts réels de l'équipe (salaires, infrastructure, licences) pour la période
2. EVM basé sur les jalons (cycle en V)
Pour les projets en cascade, attribuez des poids budgétaires aux jalons. La Valeur Acquise n'est créditée que lorsque chaque jalon est pleinement achevé et accepté.
Exemple pratique
Développement d'un CRM : BAC = 400 000 €, 8 sprints. Après le sprint 4 :
IPC = 160 000 ÷ 195 000 = 0,821 (18 % de dépassement)
IPD = 160 000 ÷ 200 000 = 0,800 (20 % de retard)
EAC = 400 000 ÷ 0,821 = 487 211 €
IPD = 160 000 ÷ 200 000 = 0,800 (20 % de retard)
EAC = 400 000 ÷ 0,821 = 487 211 €
Objections courantes à l'EVM agile
- « L'Agile n'a pas de périmètre fixe » : l'EVM fonctionne avec un backlog priorisé — le BAC représente le périmètre de la version convenue
- « Les exigences changent à chaque sprint » : utilisez un processus de contrôle des changements
- « Pas d'estimations préalables » : l'EVM nécessite une référence — les story points relatifs peuvent en constituer une
Conseils pratiques pour les chefs de projet IT
- Fixer le BAC avant le sprint, pas après
- Ne créditer que 0 % ou 100 % pour les stories en cours — pas de crédit partiel
- Suivre les tendances CPI hebdomadairement — le reporting mensuel est souvent trop tardif