Gestion des Coûts et Projets Agiles (la vidéo)

En bonus voici la vidéo des 10 premières minutes de la conférence sur la Gestion des Coûts et les Projets Agiles animée par Renaud Choné lors de l’Agile Tour 2009.

Continuer la lecture de « Gestion des Coûts et Projets Agiles (la vidéo) »

Diagramme Temps-Temps ou Courbe à 45 degrés

Le diagramme temps-temps, ou courbe à 45°,  est indispensable lorsqu’il y a eu plusieurs versions du planning pour suivre les évolutions des dates des jalons.

En anglais, ce diagramme s’appelle le milestone slip chart.

diagramme temps-temp ou courbe à 45 degrés

Les éléments du diagramme

Chaque courbe représente les évolutions de la date d’un jalon au cours du temps.

La droite en rouge clair d’équation X=Y représente l’intersection entre la planification et le présent. C’est la droite à 45°. Elle marque la séparation entre le prévu (à gauche de la droite à 45°) et le réalisé (à droite).

Les droites en pointillés rappellent la planification de référence (baseline) des jalons.

Interprétation du diagramme

Dans notre exemple:

Le Jalon 1 correspond au cas idéal sans replanification ni retard, donne une simple droite.

Le Jalon 2 correspond au cas où il y a eu un retard de 15 jours (29 septembre au lieu du 14 septembre). La courbe glisse sur la droite à 45° jusqu’à la clôture du jalon.

Le Jalon 3 montre le cas où il y a eu une replanification (suite au retard sur le jalon 2)

Le Jalon 4 montre le cas de 2 replanifications successives à 2 mois d’intervalle.

Ce diagramme est automatiquement généré par le logiciel TimePerformance.

Version 2.2

Cette version propose les améliorations suivantes:

  • Le diagramme temps-temps ou courbe à 45° (cf image ci-dessous)

    Ce nouveau diagramme permet de visualiser l’historique des dates des jalons: la planification de référence, les replanifications, les dépassements et la date de réalisation. Ce diagramme est connu en anglais sous le nom de milestone slip chart. Il peut aussi être représenté dans l’autre sens où le temps est en X et les dates des jalons en Y.

  • Possibilité de s’identifier au choix avec un nom de compte TimePerformance ou son identifiant client.

    Pour les clients qui n’ont pas eu cette option au moment de la souscription et qui souhaiteraient en bénéficier, merci de contacter notre support pour choisir le nom.

Version 2.1

Cette version propose les améliorations suivantes:

  • Feuille de Temps: possibilité de saisir les consommés dans une feuille de temps classiqueCette feuille de temps peut être utilisée conjointement à la liste de tâche ou indépendamment. Elle peut notamment permettre de corriger des valeurs ou faire un rattrapage rapide. Son utilisation est ultra simple, il suffit de cliquer sur la case et de saisir la valeur directement dans le tableau.
  • Possibilité de rouvrir une tâche close ou annuléePour corriger une erreur de clic…
  • Améliorations diverses: obtenir les détails d’une tâche non assignée, période de travail < 5 sec. ignorée, ouverture des éléments (objectifs, itération…) en un clic sur le nom.

Feuille de Temps

feuille de temps

Version 2.0

Cette nouvelle version majeure de TimePerformance introduit les premières fonctionnalités transversales par rapport aux projets:

  • Gestion de la structure de l’organisation (appelée aussi OBS)Les utilisateurs peuvent être rattachés à un service ou une direction. TimePerformance permet de gérer une structure hiérarchique de services et de sous-services. Les utilisateurs peuvent être responsables de service. La première application est la création du rapport mensuel d’activité du service (cf. point suivant).
  • Création d’un rapport mensuel d’activité pour service.Grâce à ce nouveau rapport, les responsables de services ou de département peuvent visualiser l’activité cumulée en coût et en charge de leurs collaborateurs par projet pour un mois donné. (cf. image ci-dessous)
  • Gestion de droits administrateur pour les méthodes.A la manière d’un wiki, les méthodes représentent un savoir collectif. C’est pourquoi dans TimePerformance les méthodes sont partagées et définies par tous ou presque. Cependant, afin d’éviter des erreurs de manipulation irréversibles, les administrateurs d’une méthode sont les seuls à pouvoir supprimer et restructurer ses éléments. L’ajout et l’édition continuent à ne pas nécessiter de droits particuliers.
  • Amélioration du formulaire de création des tâches avec notamment la possibilité de rattacher la tâche au plan à partir de la feuille de route.
  • Nombreuses améliorations d’ergonomie pour la planification, le filtrage des objectifs clos, accès à la feuille de route à partir de la liste des tâches etc.
diagramme de la valeur acquise avec la prévision de coût

Question sur les rôles de Product Owner et de Scrum Master

question_markDans la méthode SCRUM, il n’y a plus de Chef de Projet mais un Product Owner (Directeur Produit) et un Scrum Master.

Ce changement d’organisation engendre en pratique de nombreuses questions.

Par exemple:
– Quels rôles auront dans SCRUM les « anciens » chefs de projet ?
– Peut-on être à la fois Product Owner et Scrum Master ?
– Le Product Owner fait-il partie de l’équipe ?
– Comment le Product Owner et le Scrum Master travaillent-ils ensemble ?
– Qui est la bonne personne pour devenir le Product Owner ? le Scrum Master ?
– …

Vous trouverez de nombreux éléments de réponse dans l’article «Scrum Roles – an Unsolvable Puzzle?» par Anna Forss dans le numéro Eté 2009 de Methods And Tools, téléchargeable gratuitement.

Les Méthodes Agiles sont-elles compatibles avec l’utilisation d’un progiciel de gestion de projet ?

A l’origine des méthodes agiles, il y a le rejet des méthodes et des outils classiques de gestion de projet.

Les pionniers de l’Agilité ont donc dû revenir à la feuille Excel pour gérer leurs projets. Qu’en est-il aujourd’hui ?

La très forte augmentation de la compétition a obligé les entreprises à évoluer toujours plus vite, avec des concepts comme le Time-To-Market. La visibilité sur l’avenir s’est réduite. Les projets, toujours plus complexes, sont soumis à des changements permanents.

Ceci est incompatible avec une planification détaillée sur laquelle se fonde l’approche classique de la gestion de projet.

Les logiciels axés sur le diagramme de Gantt, le Pert ou la recherche du chemin critique, sont donc inadaptés pour les projets qui requièrent de l’agilité.

Faut-il utiliser un progiciel de gestion de projet lorsqu’on est Agile ?

Non, si le logiciel choisi est basé sur les techniques de planification détaillée. Il ne pourrait qu’introduire de la lourdeur et de la rigidité pour finalement n’apporter aucune valeur. Une feuille de calcul est alors préférable.

Oui, car il existe des nouveaux logiciels conçus pour les approches Agiles et plus efficaces qu’une simple feuille de calcul.

La gestion et la comptabilité de projet ou d’entreprise sont des fonctions qui ont vocation à être informatisées par des solutions d’entreprise.

Le logiciel de gestion de projet TimePerformance facilite le travail du chef de projet en lui fournissant des fonctions essentielles pour le pilotage et le suivi:

  • suivi 100% automatisé des coûts et des charges,
  • un tableau de bord ultra-complet en temps réel,
  • la traçabilité des évolutions,
  • le support méthodologique…

Le tableau de bord de TimePerformance fournit les indicateurs recommandés par tous les standards de la gestion de projet (PMBoK etc.). C’est particulièrement important pour l’image du projet vis à vis du Management et du Client.

Ainsi le logiciel TimePerformance évite la marginalisation des projets agiles.

Cliquez ici pour en savoir plus sur TimePerformance.

Cliquez ici pour plus de détails sur les concepts agiles supportés par TimePerformance (dans le cas particulier de la méthode agile SCRUM)

Version 1.8.5

Nouvelles fonctionnalités et améliorations:

  • Possibilité de définir une planification de référence qui sert de base de comparaison.Cette référence est utile pour figer le budget et le délai d’un projet (ex: projet au forfait).

    Dans les diagrammes, la zone en rouge est la zone d’alerte indiquant un dépassement de budget ou de délai par rapport à cette référence (cf. le diagramme ci-dessous).

    Un rapport sous forme de tableau permet de comparer de manière chiffrée le plan actuel et la référence (cf. ci-dessous).

  • Prévision des coûts réels basée sur l’estimé à terme (estimate at completion) disponible dans le diagramme de la valeur acquise.C’est la courbe en pointillés qui prolonge la courbe des coûts réalisés (cf. le diagramme ci-dessous).
  • Pour être cohérent avec la version 4 du PMBoK sortie cette année, la formule de calcul de l’estimé à terme a été modifiée dans TimePerformance.La nouvelle formule est la version dite « pessimiste » où l’indice de performance est égal à CPI * SPI (ou IPC * IPD en vf.).
  • Possibilité pour le chef de projet de clore, annuler ou mettre en pause les tâches des autres membres.
  • Changement de terminologie: les étapes s’appellent dorénavant des itérations. Un autre synonyme pour itération est « sprint ».
diagramme de la valeur acquise avec la prévision de coût
comparaison du plan actuel et du plan de référence

Réconcilier la Maîtrise d’ouvrage et la Maîtrise d’oeuvre

En termes d’organisation, la séparation de la MOA et de la MOE pour les projets informatiques est une exception française qui perdure malgré ses multiples inconvénients.

Les inconvénients de la séparation MOA/MOE

  • le développement de visions divergentes et de malentendus
  • une communication très formelle entre les équipes donc moins rapide et moins efficace
  • les responsabilités partagées et des prises de décision parfois difficiles
  • l’installation possible d’un climat de méfiance et le risque d’avoir le projet contaminé par les dissensions entre les services

moa_moe_confrontationA la moindre difficulté, le projet risque de devenir le terrain d’une lutte où les 2 clans se retranchent derrière leurs positions: la MOA réclamant les fonctions indispensables pour les utilisateurs et la MOE invoquant la faisabilité technique ou les délais trop courts.

 

Les avantages d’une équipe mixte MOA/MOE

D’abord la simplicité. Les responsabilités et les décisions appartiennent à une seule équipe.

Mais surtout cela fait ressortir en amont du projet les difficultés de coopération et de communication qui existent naturellement entre le métier et la technique. Et plus vite seront réglées ses difficultés, mieux se portera le projet. Voilà pourquoi il faut mettre MOA et MOE côte à côte.

Enfin, des solutions optimales en termes de rapport valeur business sur coût (le fameux R.O.I.) peuvent être plus facilement identifiées.

Conclusion

Pour réaliser un projet dans les meilleures conditions, il est indispensable d’avoir une vision commune unifiant les 2 visions, métier et technique, MOA et MOE. Cette vision commune se développe en travaillant ensemble sur la résolution des problèmes, la recherche de solution, voire de compromis, l’atteinte d’objectifs communs… Elle se concrétise dans la circulation libre des informations du projet en temps réel, notamment sur l’avancement du projet et de son tableau de bord.

Voilà pourquoi il semble souhaitable d’unir MOA et MOE, pas «autour des projets», mais «dans les projets».

Version 1.8.0

Nouvelles fonctionnalités et améliorations de la version 1.8.0:

  • Nouveau graphique de la Vélocité qui permet de visualiser les évolutions de la vitesse de progression d’une itération à l’autre. La définition de ce graphique (Velocity Chart) provient de la méthode agile SCRUM.

    Options: vélocité en termes de périmètre ou de valeur business, affichage de la vélocité prévue…

  • Edition possible d’une phase ou d’une itération à partir du tableau d’avancement.
  • Identification des projets utilisant une méthode en particulier.
  • Consultation du mode de réglement choisi dans la partie Administration.
graphique de la vélocité (SCRUM velocity chart)