Étiquette : Gestion de projet

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…

 

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 »

Suivre l’avancement du Projet

Suivre l’avancement est la mission n°1 du chef de projet pendant la phase d’exécution. Tout le travail de planification ne sert à rien si on ne suit pas l’avancement. L’avancement est au cœur de la gestion de projet.

Ce tutoriel présente comment se gère l’avancement avec TimePerformance.

3 bonnes nouvelles pour les chefs de projet

Tout a été fait dans TimePerformance pour simplifier le travail du chef de projet.

Suivi de l'avancement du Projet

La première bonne nouvelle est que le calcul de l’avancement est totalement automatique pour les niveaux supérieurs du plan projet. Ces niveaux sont le projet, les phases, les étapes et les livrables avec des sous-livrables (cf. structure du plan du projet).

Pour ces éléments, la technique de la valeur acquise définit la bonne façon de calculer l’avancement. Il s’agit d’une somme des avancements pondérés par les budgets. C’est standard et le logiciel fait tout.

La deuxième bonne nouvelle est qu’il n’y a pas besoin de suivre l’avancement des tâches. Dans TP, les tâches sont soit « pas commencées », soit « en cours », soit « terminées ». (toute ressemblance avec une méthode agile bien connue est fortuite 😉 ). C’est la personne qui réalise la tâche qui met à jour son statut.

Les seuls avancements restants à déterminer concernent les livrables. La troisième bonne nouvelle est que ce travail de suivi de l’avancement des livrables demande moins de 5 minutes par semaine.

Avancement d’un livrable

Il n’y a que 2 avancements qui soient sûrs: 0% (pas commencé) et 100% (terminé). Plusieurs techniques permettent d’évaluer l’avancement entre ces 2 valeurs.

Le suivi de l’avancement d’un livrable peut être fait par une saisie directe de l’avancement ou automatiquement selon 4 modes de calcul.

Chaque option a ses avantages et ses inconvénients. Le choix de l’option dépend du type de livrable et des préférences du chef de projet. Ce choix se fait dans le formulaire de chaque livrable. Dans la configuration du projet, le chef de projet peut choisir l’option par défaut de suivi d’avancement des livrables.

Saisie manuelle

Dans ce mode, le chef de projet saisit directement dans le rapport d’avancement le pourcentage d’avancement ou le reste à faire du livrable. (cf. formule entre reste à faire et avancement )

Options d’avancement automatique

Voici les 4 modes automatiques du calcul de l’avancement.

Reste à faire sur les tâches Quand cette option est choisie, toutes les tâches associées ont un reste à faire à renseigner au départ puis mis à jour automatiquement
% de tâches terminées % d’avancement = ratio du nombre de tâches terminées.
Ex: 4 tâches terminées sur 10 ⇒ 40% d’avancement
% de la charge consommée Ex: Une formation de 4 jours (donc 4 jours-hommes budgétés). 2 jours déjà effectués. L’avancement est de 50% = 2/4
% du délai écoulé Ex: La gestion de projet pour la phase d’étude qui dure 3 mois. A la fin du premier mois, l’avancement est de 33% = 1/3

Note: Le calcul automatique à partir des tâches exige que toutes les tâches rattachées au livrable soient créées en amont.

Quelques conseils

Conseil n°1: La simplicité

Dans le doute ou au départ, choisissez toujours l’option la plus simple: la saisie manuelle. Cela permet de garder le contrôle.

Conseil n°2: La bonne granularité

Choisissez la bonne granularité pour les livrables du projet.

Si les livrables sont trop gros, l’avancement risque d’être très approximatif. Dans ce cas, décomposez les livrables en sous- livrables.

Si les livrables sont trop petits, ce sera très lourd à gérer. Dans ce cas, il est possible de regrouper plusieurs livrables pour en faire un plus gros.

La bonne granularité des livrables est une affaire de compromis entre précision de l’avancement et charge de gestion.

Conseil n°3: Clore les livrables

Si un livrable est à 100% d’avancement, pensez à le clore en changeant son statut à Terminé. Ainsi vous vous assurez qu’il ne reste aucune tâche non terminée rattachée à ce livrable.

Conseil n°4: La régularité

Les saisies et le suivi de l’avancement doivent être faits au moins une fois par semaine.

Si cela n’est pas fait, cela signifie que les écarts ne sont pas surveillées, et donc que le projet est sans pilote. Que fait le chef de projet ?

Conseil n°5: Mixer les options

Voici une technique pour combiner les avantages de chaque option.

Pour un livrable, commencez par saisir manuellement l’avancement. C’est simple et ne requiert pas d’identifier immédiatement toutes les tâches et d’estimer leur reste à faire.

Puis lorsqu’on approche de la fin (par exemple à 70% d’avancement), basculez le livrable en mode «reste à faire sur les tâches. Saisissez le reste à faire au niveau des tâches restantes. A ce stade, l’identification des tâches restantes devrait être simple et la saisie des restes à faire moins lourde.

Avec cette technique, on combine la simplicité au début et la précision sans lourdeur excessive vers la fin.

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 »

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.

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».

Pourquoi la valeur acquise…

diagramme valeur acquise

Diagramme de la Valeur Acquise

La technique de la Valeur Acquise répond à une question essentielle du sponsor d’un projet: Combien coûtera le projet ? Est-ce que le budget sera respecté ?

L’erreur commune en matière de suivi des coûts consiste à calculer l’écart de coût comme la différence entre le coût réel et le budget à date. Si le projet est en retard ou en avance, on compare le coût d’une chose avec le budget prévu pour autre chose.

Dans la technique de la valeur acquise, on compare le coût réel au budget prévu pour ce qui a été fait, et non le budget à date. Ainsi les coûts sont comparables car ils portent sur le même périmètre.

Définition de la valeur acquise

La valeur acquise représente la valeur de ce qui a été fait (= acquis). La valorisation est calculée selon le budget initial.

Ainsi la Valeur Acquise (VA) est le Coût Budgété du Travail Effectué (CBTE).

L’Ecart de Coût (EC) du projet est égal à la valeur acquise moins le coût réel.

EC = VA – CRTE = CBTE – CRTE où CRTE est le Coût Réel du Travail Effectué (c.-à-d. le coût réel).

Si EC < 0, cela veut dire qu’on a payé trop par rapport à ce qu’on a acquis (dépassement de budget) et inversement.

L’erreur commune évoquée précédemment est de faire la différence: budget à date moins le coût réel.

EC ≠ CBTP – CRTE où CBTP est le Coût Budgété du Travail Planifié, i.e. le budget à date.

Remarque: en plus d’informer sur les coûts, la valeur acquise renseigne simultanément sur les délais. Il suffit de faire la différence entre la Valeur Acquise et la Valeur qu’on avait prévue d’acquérir, égale au Budget à date. (VA – CBTP, si > 0 projet en avance, si < 0 projet en retard).

Trésorerie et Résultat

La valeur acquise permet de calculer le Résultat du projet tandis que la différence entre le coût réel et le budget à date s’apparente à la Trésorerie du projet.

Comme pour une entreprise, on peut avoir un résultat négatif (ex: vente à perte) tout en ayant une trésorerie positive. En faisant fondre les stocks par exemple.

Pour les projets, le risque est de consommer tout le budget sans atteindre le résultat prévu.

La valeur acquise permet de maîtriser ce risque en indiquant en permanence le résultat courant du projet.

Le calcul de la valeur acquise

Pour faire de la gestion de projet, il y a 2 écoles: la feuille de calcul (Excel, Calc etc.) et le progiciel.

Dans le premier cas, le calcul de la valeur acquise s’avère plutôt complexe. Dans le second, les progiciels traditionnels nécessitent un investissement important qui réserverait la technique de la valeur acquise aux gros projets.

Avec notre logiciel de gestion de projet TimePerformance, nous essayons de changer cet état de fait en fournissant une solution simple qui permet l’utilisation de la technique de la valeur acquise sur tous les projets et sans effort.

Voir aussi cet article qui présente le diagramme de la valeur acquise.

Pourcentage d’avancement et reste à faire

Le pourcentage d’avancement se calcule à partir du reste à faire et du consommé.

Avancement et reste à faire

Exemple: 7 heures déjà effectuées et 3 heures restant à faire, l’avancement est de 7 / (7+3) = 70%.

Lorsque le consommé n’est pas disponible, l’avancement peut être estimé avec la formule suivante.

Avancement et reste à faire

Mais attention, cette formule est très approximative (cf exemple ci-dessous). Elle peut même donner un avancement négatif dans le cas où le reste à faire est supérieur à la charge prévue initialement.

Par exemple, on a travaillé 7h sur une tâche et il reste 7h à faire. On a donc fait 50% du travail. Mais si la tâche avait été estimée initialement à 10h, la 2ème formule donne un avancement de 30% (= 100% – 7h / 10h), tandis que la 1ère formule donne toujours 50%.

Découvrez les autres options pour mesurer son avancement dans TimePerformance.

 

Tâche ou Livrable ?

point d'interrogationConfondre les livrables du projet et les tâches associées, c’est confondre le problème et sa solution.

Pour les chefs de projet, qui sont impliqués à la fois dans la définition du problème et la recherche d’une solution, faire la distinction n’est pas si simple.

Les outils traditionnels de gestion de projet entretiennent la confusion avec un Gantt de tâches et de macro-tâches. La distinction entre les phases, les livrables et les tâches ne saute pas aux yeux.

Dans TimePerformance, ces 3 concepts sont clairement identifiés (lire structure du plan du projet) parce qu’ils répondent à des interrogations différentes – le quand, le quoi et le comment – qu’il convient de distinguer.

Voici un article pour aider à faire facilement la distinction entre Tâche et Livrable…

Définitions

Les livrables représentent les produits, les « outputs » du projet. Ce sont donc des objectifs collectifs pour toute l’équipe. Les livrables sont imposés à l’équipe. 85% des livrables sont définis par le client. C’est une notion métier ou business.

Les tâches représentent le travail, c-à-d les actions que doivent réaliser les membres du projet. Les tâches sont définis par les processus techniques choisis par l’équipe. C’est donc une notion technique,  en général sans intérêt pour le client final.

Pour distinguer les 2 notions facilement, il est recommandé de faire commencer le nom des tâches par un verbe pour marquer une action (ex: «Rédiger le rapport», «Coder» etc.) et d’utiliser un groupe nominal pour les livrables (ex: «Analyse de faisabilité», «Etude de marché», «Fonctionnalité Paiement en ligne» etc.).

La relation entre les livrables et les tâches est simple. Les tâches participent à la réalisation d’un livrable.

Donc chaque livrable a une ou plusieurs tâches associées, et chaque tâche est associée à un et un seul livrable.

Un livrable avec 1 tâche est généralement le signe de confusion entre les 2 notions ou d’un problème de granularité du livrable.

Planification et Affectation

Au final, ce que veut le client, c’est un résultat à une date donnée, et non des tâches à une date donnée. C’est pourquoi dans TimePerformance, on planifie les livrables, pas les tâches.

On pourrait avoir une planification des tâches mais cela introduit une lourdeur au moment de la planification, rend plus difficile la replanification, réduit l’agilité, sans gain significatif dans la prédictibilité du projet du fait de tous les aléas sur un projet.

Pour réaliser un livrable, il y a plusieurs tâches à faire. Ces tâches sont en général réalisées par plusieurs personnes. Il n’est donc pas possible d’affecter un livrable à une personne. Dans TimePerformance, on affecte les tâches, pas les livrables.

Dans TP, la planification des livrables est de la responsabilité du chef de projet. Par contre l’affectation des tâches peut être faite par le chef de projet, ou en mode auto-organisation, c-à-d l’équipe projet gère elle-même les tâches, création et affectation. C’est un choix d’organisation d’équipe.