Gestion de projet charge et délai

GESTION DE PROJET : La charge n’est pas le délai, Pourquoi il est important de ne pas confondre les deux ?

En tant que chef de projet, il y a des phrases qui peuvent quelque peu irriter ou profondément nous énerver. Pour ma part, j’en retiendrais 2 emblématiques et symptomatiques d’une mauvaise compréhension de la notion de charge et de délai et de ce qu’ils englobent comme réalité.

La première est la très récurrente mais non moins irritante :

« Non mais c’est facile, il suffit de faire ça et cela ne devrait nécessiter que quelques jours de travail ? »

Cette phrase peut paraitre anodine mais dans le cas d’un projet elle peut faire beaucoup de dégâts. Pourquoi me demanderez-vous ? Tout simplement parce qu’elle est révélatrice d’une mauvaise compréhension des efforts que nécessite la conception de produits web ou digitaux.

« En Web et en conception de produit digital rien n’est jamais facile ou simple »

Première rectification, qu’il est donc nécessaire de faire : en web et en conception de produit digital rien n’est jamais facile ou simple. Il peut y avoir des complexités cachées qui ne peuvent être découvertes ou mises en lumière que grâce aux travaux d’analyse et de réflexion de la chef de projet et des développeurs mobilisés sur le projet. Ce travail est important et doit être réalisé car il permet bien souvent d’anticiper d’éventuelles problématiques bloquantes et de les régler en début de projet. Ce qui peut s’avérer beaucoup moins couteux sur le long terme. Il est donc primordial d’expliquer que, derrière l’apparente facilité ou simplicité d’utilisation de certaines applications, se cachent des heures de travail et une certaine forme d’humilité face aux défis que peuvent parfois impliquer la conception d’application web.

La charge estimée et le délai de réalisation sont 2 paramètres de gestion de projet distincts

L’autre phrase qui risque de braquer fortement votre chef de projet concerne l’amalgame entre la charge et le délai. Elle peut prendre différente forme mais la forme la plus courante est la suivante :

« Puisque la charge estimée est de 25JH, on devrait avoir cette fonctionnalité en production d’ici 1 mois ? »

A première vue cette phrase peut paraitre logique mais en réalité elle ne l’est pas et ce pour plusieurs raisons :

  • La première, c’est que la charge est une estimation brute du nombre de jours nécessaires pour réaliser une tâche. Elle ne tient pas compte du taux de disponibilité dont dispose la ressource en charge de cette dernière.
  • La deuxième, c’est qu’il est primordial de garder à l’esprit que des micro-tâches propres à chaque métier peuvent venir grignoter du temps normalement destiné à la tâche initiale estimée.

Alors, que faire pour éviter cette erreur et échafauder des plannings prévisionnels qui tiennent compte de la réalité des activités de chaque ressource qui devront intervenir sur le projet ?

Moduler les calculs grâce au paramètre « taux de disponibilité » pour limiter les erreurs de planning

Forte de mon expérience de 10 ans en tant que chef de projet, je conseillerai tout d’abord de rappeler gentiment à vos interlocuteurs que la charge estimée d’une tâche ne correspond aucunement au délai dans lequel elle sera exécutée car elle tient rarement compte de la complexité et des « à-côté » que doivent gérer en parallèle tout professionnel.

En effet, comme déjà abordé plus haut dans l’article, une ressource ne peut que très rarement être dédiée à 100% à une tâche. Cela s’explique par la présence de micro-tâches généralement non intégrées à l’estimation réalisée et qui viennent parasiter le taux de disponibilité de la ressource en question. Afin d’éviter d’être prise au dépourvu, j’ai donc pris l’habitude en fonction du poste occupé, de n’appliquer qu’un taux de disponibilité de 80%, voir moins si cela s’avère nécessaire. Selon cette logique, pour obtenir un délai réaliste, il suffit alors de diviser la charge par le taux de disponibilité. Ce qui donne l’équation suivante :

charge estimée / taux de disponibilité = délai estimé.

Une stratégie de calcul et de gestion de projet qui permet notamment de tenir compte de la réalisation de tâches récurrentes propres à chaque type de poste. Par exemple, pour un poste de développeurs, les tâches répétitives peuvent être les suivantes :

  • Installer et paramétrer son environnement de dev en local
  • Réactualiser son dépôt et environnement avec les nouvelles fonctionnalités mergées sur l’environnent de développement partagé
  • Réaliser les différentes livraisons des parties codées sur l’environnement de dev partagé, l’environnement de recette, de pré-production et de production
  • Maintenir les différentes plateformes de développement et de test
  • Réaliser de tests unitaires pour vérifier le bon fonctionnement du code produit

Ces dernières ne font pas toujours l’objet d’une estimation de charge claire et précise dans la mesure où elles sont récurrentes. Jongler avec le taux de disponibilité de la ressource permet de les réintégrer dans le calcul et de les faire apparaitre sur les plannings prévisionnels des projets. Ce qui est valable pour le poste d’un développeur l’est aussi pour n’importe quel autre poste devant intervenir sur la conception d’un produit web ou digital. Avec cette technique, le taux d’erreur côté gestion de projet et côté planification permet d’être amoindri et de coller davantage au réalité des Métiers.