Initiation à la Valeur Acquise (Earned Value)

En gestion de projet, la technique standard de suivi de projet s’appelle la Valeur Acquise. Sa principale mission est la mesure des écarts par rapport au plan, et donc la maîtrise du projet. Cette technique fait partie intégrante des référentiels méthodologiques (PMBoK, IPMA…). En anglais, son nom est Earned Value Management (EVM).

Objectif de la Valeur Acquise: Maîtriser les écarts de coût et de délai

Une bonne gestion de projet passe nécessairement par la maîtrise des écarts.

Voyons ensemble comment le diagramme de la Valeur Acquise nous permet de visualiser facilement les écarts.

Valeur Acquise - courbe en S

Capture d’écran de TimePerformance, le logiciel de gestion de projets par la valeur acquise.

Sur ce diagramme, on y trouve 3 courbes.

  • La courbe bleue représente le plan.
  • La courbe verte représente l’avancement réel.
  • La courbe rouge représente le coût réel (hors la partie en pointillés).

Les positions relatives des courbes montrent les écarts de coût et de délai du projet.

La courbe verte est au-dessus de la courbe bleue. Donc l’avancement est supérieur au plan. Le projet est donc en avance (écart de délai).

La courbe rouge est au-dessus de la courbe verte. Donc le coût réel est supérieur à l’avancement réel. Le projet est donc en surcoût (écart de coût).

Remarque: Le diagramme de la valeur acquise est aussi connu sous le nom de Courbe en S pour sa forme caractéristique.

Qu’est-ce que la Valeur Acquise ?

La valeur acquise, c’est la courbe verte, c.-à-d. l’avancement réel du projet. On appelle «valeur acquise» l’avancement réel quand il est valorisé en euros. L’intérêt de valoriser l’avancement en euros est de pouvoir comparer sa valeur par rapport au budget (le plan) et au coût réel.

Le principe de la Valeur Acquise, c’est simplement de donner une valeur en euros à l’avancement réel pour le comparer à un budget et à un coût réel.

A partir des 3 valeurs, valeur acquise, budget à date et le coût réel, la technique de la valeur acquise fournit des formules simples pour calculer des écarts et des indices de performances.

Le + de la Valeur Acquise: la prédiction à terme

Le fait d’avoir calculé les écarts sur le projet permet de faire des prédictions par extrapolation. Dans la technique de la valeur acquise, on s’intéresse à prédire le point d’atterrissage du projet, ce qu’on appelle l’estimé à terme.

Dans le diagramme ci-dessus, la prévision est représentée par la partie en pointillés de la courbe rouge.

La technique de la valeur acquise prédit dans l’exemple que le projet se terminera 3 semaines en avance avec un surcoût de 10%.

Comment calculer la Valeur Acquise ? Comment valoriser un avancement ?

Le principe du calcul est simple: chaque élément du projet a un poids qui correspond à son montant dans le budget. Ainsi, à chaque fois qu’une tâche est terminée ou qu’un livrable est achevé, le montant du budget prévu pour cette tâche ou ce livrable s’ajoute à la valeur acquise du projet.

Malgré sa simplicité – ou plutôt grâce à sa simplicité – cette technique est très efficace et facile à utiliser. Elle fournit des informations essentielles au pilotage.

Le seul réel obstacle à la démocratisation de la valeur acquise est la lourdeur des calculs. Ils sont fastidieux du fait de la volumétrie des données et de la nécessité d’historiser les valeurs. De plus, la prise en compte des changements en cours de projet constitue un réel challenge pour la mise à jour des courbes. Sans outillage suffisant, la mise en œuvre de la valeur acquise devient rapidement un casse-tête pour le chef de projet.

Sur ce dernier point, nous vous invitons à essayer gratuitement notre logiciel de gestion de projets, qui est la solution la plus simple et la plus facile pour bénéficier de la technique de la valeur acquise.

Perles de PMO

Un peu d’humour pour la rentrée…

Voici quelques perles de vrais PMO glânés au cours des rencontres, qui nous ont laissés sans voix.

Nous: «Il y a plein de livrables et d’étapes dans TimePerformance dont l’avancement est à 100%. Il faudrait les clore, non ?»

PMO: «Ben, l’avancement est à 100% mais ce n’est pas vraiment terminé. Il y a quelques retouches à faire ici et là…»

Le même pour le même projet…

La prédiction dans le diagramme de la valeur acquise dans TimePerformance montre clairement que le projet qui devait finir en octobre ne finira pas avant avril-mai de l’année suivante. (ce qui s’est démontré vrai par la suite)

PMO: «On le sait tous à la DSI mais il ne faut surtout pas le dire.»

Un autre.

 PMO: «Nous sommes un centre de coûts….. Donc on ne gère pas les coûts.»

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…

Agilité et Lean Startup

L’Entreprise 2.0 reste un concept un peu vague bien que le changement soit pressenti comme inévitable.

Le 2.0 est bien plus que de la collaboration informelle. C’est l’ensemble de toutes les réponses aux bouleversements de notre monde actuel.

Il existe une déclinaison concrète du concept d’Entreprise 2.0 pour les startups: la Lean Startup.

Dans la vidéo ci-dessous,  Abby Fitchner nous présente les nombreuses similitudes entre Lean Startup et l’Agilité, qui représente une autre évolution majeure et récente dans le fonctionnement des entreprises.

[vimeo 27797408]

How Lean Startup Pushes Agile to the Next Level from Abby Fichtner, Hacker Chick on Vimeo.

Suivi des temps = flicage ?

La mise en place du suivi des temps déclenche souvent une réaction épidermique de la part des équipes, qui suspectent leur management de vouloir les surveiller, voire de vouloir les espionner. Le suivi des temps est-il une forme de « flicage »?

Le suivi des temps ne sert pas à «fliquer». En effet, il repose entièrement sur une action volontaire de la personne concernée.

A l’inverse, pour faire du «flicage», il faudrait un vrai système de surveillance avec des logiciels qui espionnent à l’insu des personnes.

Le suivi des temps est généralement réalisé sur la base d’une déclaration de bonne foi sans aucune forme de vérification. On fait confiance aux gens pour déclarer leurs temps, et ceux qui veulent «tricher» peuvent donc le faire en toute impunité.

A quoi sert le suivi des temps ?

En premier lieu, le suivi des temps sert à comptabiliser.

Comptabiliser sert à donner de la visibilité au management et est la base d’une bonne gestion. Ce n’est peut-être pas « fun », mais c’est nécessaire, surtout dans un environnement professionnel.

On peut réussir des projets sans gestion, mais c’est risqué. On peut aussi faire de la comptabilisation implicite, comme dans SCRUM, mais cela implique certaines contraintes pas toujours faciles à respecter (taille de l’équipe constante, durée des sprints identiques etc.).

En général, le suivi des temps reste le brique de base de la comptabilité du projet, indispensable à sa gestion et à son pilotage.

Le suivi des temps peut aussi être utilisé par les premiers concernés, ceux qui suivent leur temps.

A l’instar du sportif qui recherche la performance et surveille son chrono, suivre son temps permet de mieux se connaître dans sa façon de travailler et de s’améliorer. Un exemple évident de potentiel d’amélioration concerne l’estimation des futures tâches.

Cette utilité du suivi des temps est vraie au niveau de l’individu mais aussi au niveau de toute l’équipe.

Dans un article précédent, nous avons fait un petit retour d’expérience sur ce que le suivi des temps peut apporter à une équipe de développement logiciel en mode agile.

Les 2 mauvaises raisons de ne pas suivre son temps

Raison n°1: Invoquer le manque de temps.

Ceci est un prétexte car le suivi des temps ne prend que quelques minutes par semaine. La vraie raison est qu’on n’en a pas envie car ce n’est pas une activité plaisante, bien que nécessaire. Dans ce cas, le manager doit rappeler l’intérêt et la nécessité, à mettre en comparaison du faible effort à produire.

Raison n°2: Crier au flicage.

Ceci traduit un climat de méfiance et de peur. Dans ce cas, il faut rétablir rapidement un climat de confiance.

Conclusion

Le suivi des temps n’est donc pas du flicage mais simplement une bonne pratique de gestion, voire d’autogestion. C’est une affaire de discipline personnelle et de transparence vis à vis du management. Cela peut aussi devenir un moyen d’apprentissage et d’amélioration, individuel et en équipe.

Agilité et suivi des temps, pour quoi faire ?

Le suivi des temps déchaîne rarement l’enthousiasme dans les équipes et bien des managers traditionnels peinent à le mettre en place. Cependant il trouve un nouveau sens et se renouvelle en mode agile en devenant une source précieuse de feedbacks pour toute l’équipe, principe fondamental de l’Agilité.

Feedback et Suivi des temps (Time Tracking)

timetrackingEn matière de gestion de projet, le processus d’estimation reste un exercice difficile et approximatif, alors qu’il est essentiel pour déterminer la viabilité du projet. Et le suivi des temps est le seul moyen d’obtenir un feedback pertinent sur ce processus critique.

Dans le domaine du développement logiciel, les tentatives de rationalisation du processus d’estimation ont abouti à des résultats médiocres malgré la complexité des modèles analytiques développés (points de fonction, Cocomo etc.). En général, estimer un projet reste un processus empirique basé sur l’intuition et l’expérience des équipes, agrémenté de techniques de recherche de consensus. Mais la fiabilité des processus empiriques est soumise à caution et on constate en pratique des marges d’erreur importantes.

En mode Agile, on a la chance de pouvoir vite améliorer le processus d’estimation empirique. Il suffit de fournir à l’équipe le feedback adéquat: les écarts entre les estimations et le temps réellement passé au niveau de chaque item du backlog.

Alimenter en informations chiffrées les rétrospectives (SCRUM) est le premier objectif du suivi des temps en mode Agile. L’équipe fournit un retour qualitatif et humain, le suivi des temps le complète par un feedback quantitatif et objectif.

L’indicateur de Vélocité seul ne permet pas d’identifier les causes des problèmes. En effet, calculé au niveau du Sprint (= itération), c’est un indicateur trop macroscopique influencé par de nombreux facteurs. De plus, la Vélocité n’est pas une mesure mais le paramètre d’un modèle linéaire simple entre complexité et charge de travail.

Le suivi des temps permet aussi d’avoir une mesure précise du facteur de concentration (focus factor) pour ceux qui l’utilisent.

Pour être utile, le feedback doit se faire au même niveau de détails que le processus d’estimation (i.e. backlog item, user story, la fonctionnalité…). C’est à ce niveau que le suivi des temps prend toute sa valeur (et non au niveau des tâches). Il permet de mesurer la fiabilité de chaque estimation, prise séparément. Il est alors possible d’ajuster le processus d’estimation pour prendre en compte d’autres facteurs que ceux du modèle générique.

Voici quelques leçons apprises chez Time Performance grâce au suivi des temps avec TimePerformance:

  • Nous passons environ 30% du temps sur des sujets qui ne font pas partie de la feuille de route du produit.

    Dans ces 30%, on retrouve les refactorings, les corrections d’anomalies, les petites améliorations, les tests utilisateurs…

    Le suivi des temps nous a permis de budgéter pour les itérations suivantes ce qui n’était pas dans la feuille de route.

  • Les tâches les plus complexes ne sont pas celles qui relativement prennent le plus de temps.

    Certaines tâches sont très simples techniquement mais prennent néanmoins du temps. Et la relation entre complexité technique et charge de travail n’est pas linéaire.

    Par exemple, il peut être nécessaire de faire de nombreuses retouches avec des allers-retours avec les utilisateurs. Il y a aussi des «coûts fixes», car même pour une fonctionnalité simple, il faut écrire des tests et de la documentation.

    Attention donc à ne pas sous-estimer le temps nécessaire sous prétexte que c’est simple techniquement.

  • Notre perception du temps est très subjective, bien plus qu’on ne le pense.

    Certaines heures paraissent être des minutes et certaines minutes paraissent durer des heures. Tout dépend si ce qu’on fait nous plaît ou non.

    Par exemple, certains se font une montagne de devoir remplir une feuille de temps alors que cela ne prend que quelques minutes par semaine. Et on retrouve les mêmes à la machine à café en train de discuter depuis 45 minutes sur le temps qu’il fait. L’exemple fonctionne aussi avec l’écriture des tests, de la documentation… Tout le monde se reconnaîtra, nous les premiers.

    Le suivi des temps peut permettre à chaque individu d’objectiver le temps qu’il passe réellement sur les tâches.

  • Notre marge d’erreur sur les estimations était plus importante sur les nouvelles fonctionnalités que sur les évolutions.

    En y réfléchissant, c’est assez logique. D’abord le risque est plus important pour une fonctionnalité importante et totalement nouvelle. La solution imaginée au moment de l’estimation peut ne pas marcher et nécessiter plusieurs ajustements. Les impacts sont aussi plus importants et des refactorings du code et des tests existants sont très probables.

Un suivi des temps efficace est absolument essentiel pour les équipes agiles pour maîtriser leur processus d’estimation. Cela mérite bien qu’on y passe quelques minutes par semaine.

Suivi des temps et gestion du projet

Traditionnellement, la feuille de temps sert principalement à suivre les coûts réels du projet en comptabilisant le nombre de jours travaillés.

En mode Agile, il est recommandé des équipes stables et des affectations à plein temps, ce qui rend la feuille de temps inutile.

Cependant la réalité des entreprises est souvent bien différente du cas idéal:

  • les personnes participent à la vie de l’entreprise (réunion de service, aider un collègue, veille, réorganisation…);
  • les personnes travaillent sur le projet mais peuvent être appelées en urgence sur d’autres sujets;
  • la spécialisation d’une personne ne permet pas une affectation à plein temps;
  • Une compétence rare est réclamée par de nombreux projets …

En pratique, le suivi des temps est indispensable pour connaître le temps réellement passé sur le projet. Il permet notamment de constater un écart entre affectation prévue et affectation réelle, qui explique dans de nombreux cas les retards dans les projets.

Même en mode Agile, le suivi des temps est en général nécessaire pour gérer le projet.

Vaincre les résistances

La mise en place du suivi des temps dans une équipe est un moment délicat où il faut faire preuve de leadership pour porter la vision.

Voici les 3 clés pour réussir la mise en place du suivi des temps:

  1. Donner du sens. C’est l’objet de cet article et la principale mission du manager ou du SCRUM Master.
  2. Faciliter la saisie par l’équipe. C’est ce que nous avons fait chez Time Performance avec notre logiciel TimePerformance en proposant 2 moyens complémentaires pour suivre facilement  son temps: une feuille de temps (déclaration a posteriori) et une liste de tâches avec une fonction type «chronomètre» (suivi au fil de l’eau).
  3. Montrer des résultats, c.-à-d. exploiter les informations et communiquer les résultats à l’équipe. C’est sans doute le plus important et ce qui permettra de convaincre les plus sceptiques.

Il y a encore quelques années, écrire des tests ou documenter le code n’étaient pas plus populaires que le suivi de temps parmi les développeurs. Aujourd’hui, c’est le quotidien des équipes agiles qui s’en font une fierté. Dans quelques années, un bon suivi des temps pourrait devenir le signe de maturité et d’autogestion d’une équipe…

 

Gestion des Coûts et Projets Agiles

Présentation sur la Gestion des Coûts et les Projets Agiles animée par Time Performance lors de l’Agile Tour 2010.

Gestion des coûts et Projets Agiles

Valeur Acquise: des formules du PMBoK à la pratique

La technique de la Valeur Acquise (Earned Value Analysis ou EVA) est présentée dans le PMBoK comme une technique essentielle de gestion de projet. Pourtant elle n’est que rarement pratiquée…

Une formation sur la gestion de programme a donné l’occasion de faire un petit sondage sur les usages de la technique de la valeur acquise. Sur les 9 chefs de projet expérimentés (>10 ans), 5 connaissaient la théorie et les formules – il y avait des personnes certifiées PMP dans le groupe – mais aucun ne l’utilisait en pratique.

Ce sondage n’a pas une grande valeur statistique mais il révèle une triste réalité sur l’état de maturité de la gestion de projet dans notre pays.

Ce que dit le PMBoK

Dans le processus Contrôle des Coûts du PMBoK (§7.3), on ne trouve qu’une seule technique: l’analyse de la valeur acquise (Earned Value Analysis). Plusieurs pages lui sont consacrées, ce qui démontre son importance.

Le PMBoK donne un avertissement implicite en cas de non utilisation de la valeur acquise:

Continuer la lecture de « Valeur Acquise: des formules du PMBoK à la pratique »

10 façons de se planter avec Scrum et XP

Pour tous les fans de l’Agilité et du développement logiciel, le site d’InfoQ est une mine d’informations et de ressources utiles.

Nous vous invitons à regarder la présentation intitulée: «10 ways to screw up with SCRUM and XP». Réalisée par Henrik Kniberg, elle a été filmée sur l’Agile Tour 2008.

En résumé, voici les 10 façons de se planter avec Scrum et XP:

  1. Croire à un miracle de l’Agilité
  2. Incapacité à définir ce que signifie «Terminé» (Definition of Done) ou à suivre la définition en pratique
  3. Incapacité à gérer la Vélocité (mauvaise utilisation, tricher sur la vélocité réelle…)
  4. Rétrospectives inefficaces
  5. Manque d’engagement de l’équipe
  6. Incapacité à bien gérer la dette technique
  7. Problème de travail en équipe (mauvaise définition des rôles, pb de coopération, interférence du management…)
  8. Problème avec le Product Owner (disponibilité, pouvoir, implication, mauvaise gestion du product backlog…)
  9. Peur de fusionner les développements car trop complexe à faire
  10. Problème d’utilisation du tableau des tâches (mise à jour peu fréquente, complexité…)

Timeboxing

Le Timeboxing est une technique de gestion du temps utilisée dans les méthodes agiles pour la planification et la maîtrise des délais. Cet article en rappelle le principe et souligne les différences avec les approches traditionnelles.

Un concept très simple

Le Timeboxing est une division du temps en périodes successives d’une durée égale et relativement courte. Pour un projet, la durée recommandée des périodes est entre 2 et 6 semaines.

Cette technique est utilisée dans le domaine du développement logiciel pour imposer des livraisons fréquentes et régulières. L’objectif est d’accélérer le cycle de développement et le feedback des utilisateurs. Il s’agit aussi de lutter contre les problèmes bien connus de gestion du temps (cf. effet tunnel, lois de Parkinson et de Hofstadter, syndrome de l’étudiant etc.).

Dans le cas du développement logiciel, chaque période se conclut par une livraison. Elle est assimilable à une boîte dans laquelle il faut faire entrer le maximum de nouvelles fonctionnalités. La taille de la boîte est imposée et correspond à la charge de travail réalisable pendant la période. Le principal enjeu de la planification consiste à optimiser l’espace de chaque boîte en fonction de la priorité de chaque fonctionnalité et du temps nécessaire pour la développer.

Différence avec l’approche traditionnelle

En général, les techniques agiles prennent le contrepied de l’approche traditionnelle. Le Timeboxing n’échappe pas à la règle.

Continuer la lecture de « Timeboxing »