Vous réalisez des retroplannings ? Alors, allez-vous jusqu’au bout de la démarche et votre retroplanning tient-il toutes ses promesses ?

Pour quelle raison essentielle est-ce qu’un retroplanning est requis ?

Un retroplanning est un ordonnancement amont ou, pour dire les choses plus simplement, une planification du projet à partir d’une date de fin. Imaginons un client qui souhaite disposer d’un nouvel équipement. Au lieu de demander dans combien de temps il peut l’obtenir, il indique l’échéance à laquelle il souhaite en disposer. Notez que la stratégie de pilotage s’oriente nettement vers les délais : c’est important et nous y reviendrons plus tard. En conséquence, le Chef de projet va remonter le fil de son histoire à partir de cette échéance pour répondre à cette demande, et la réponse devrait normalement être formulée de cette façon : “oui, c’est faisable si nous nous y mettons à partir de telle date !

Maintenant que le décor est planté, je m’interroge toujours sur la suite. Que devient ce retroplanning ? Qu’en est-il de la promesse qui l’accompagne ? Plus concrètement, le planning lui-même est-il réellement mis en oeuvre aussitôt ? Est-il retraité pour être exploitable ?

Que vous soyez dans l’un ou l’autre de ces cas, voici les étapes que vous devriez normalement franchir pour réaliser votre retroplanning dans votre outil de gestion de projet préféré. Vous pourrez ainsi noter si vous vous arrêtez en chemin ou si vous êtes en mesure d’aller jusqu’au bout du chemin.

Pour les heureux gagnants, félicitations ! Pour les autres, rendez-vous après la dernière étape…

 


8 étapes pour bien faire :

1. Vous sélectionnez l’ordonnancement amont et fixez l’échéance finale.

2. Vous définissez tâches, liaisons, durées et compétences. Dès lors que la 1ère tâche est créée, elle est planifiée “le plus tard possible” à partir de l’échéance finale. Si cette tâche est liée à une autre par un lien fin-début, cette dernière s’ordonne juste avant. Et ainsi de suite… Comme tout est planifié le plus tard possible, il n’existe aucune marge sur les tâches qui ne sont pas sur le chemin critique. Vous obtenez au final une date de début de projet et pouvez répondre au client que c’est faisable à partir de cette date (si les compétences sont évidemment disponibles.)

3. J’espère que vous n’avez pas vendu au client le retroplanning, car il est temps de basculer en ordonnancement aval, c’est-à-dire de planifier le projet à partir d’une date de début. En effet, vous n’allez pas attendre le dernier moment pour réaliser les tâches sauf si vous souhaitez ne pas tenir la promesse de l’échéance finale ! Nous savons que les projets prennent naturellement du retard. Dans Microsoft Project ®, si les contraintes de date des tâches récapitulatives sont modifiées et affichent désormais “dès que possible”, vous pourrez noter que la contrainte de date des tâches n’a pas été modifiée et affiche toujours “le plus tard possible.”

4. Prenez votre courage à deux mains et modifiez la contrainte de date de vos 400 tâches en “dès que possible.” La marge totale des tâches qui ne sont pas sur le chemin critique apparaît : elle est représentée ici en vert, juste après les barres bleues de tâche et la durée de la marge est quantifiée à droite des barres vertes. Elle représente le retard qu’il est possible de prendre sur une tâche sans remettre en cause la date de fin du projet. Autre surprise, moins réjouissante : la présence de conflits de surutilisation de ressources : une ressource planifiée sur plusieurs tâches en même temps. On peut les détecter à l’aide des silhouettes rouges situées dans la 2ème colonne à gauche. Je sais : il n’y avait pas ce genre de désagrément dans le retroplanning mais on ne pouvait quand même pas le vendre au client. On pourrait imaginer ajuster le planning et résoudre ainsi ces conflits tout en respectant l’échéance finale. Ceci dit, dans tous les cas, vous ne pouvez pas décemment croire que vous finirez le projet à cette échéance. C’est sans compter les imprévus, la survenance des risques,… Il faut donc se préserver de la marge en fin de projet pour amortir ces retards potentiels.

5. Décalez la date de début de projet en amont, ce qui devrait avoir pour effet de générer de la marge en fin de projet. De combien ? D’aucuns vous diront de 20% sans hésiter, mais sans donner plus d’explications plausibles que celle qui prévaut pour les 3% de déficit public… Nous en reparlerons dans un prochain post. Dans cet exemple, on a pris 2 semaines de marge en fin de projet.

6. Remplacez les compétences par des ressources, intégrer les diverses contraintes temporelles, celle de coût,… et visualiser les nouveaux conflits de surutilisation de ressources ou identifier les problèmes d’affectation de ressources sur plusieurs projets.

7. Résoudre ces conflits.

8. Vérifiez que l’impact de ces résolutions n’empiète pas considérablement sur la marge en fin de projet. Sinon, il sera probablement nécessaire de décaler de nouveau la date de début de projet en amont.

Félicitations !!! Vous êtes au bout du chemin. Alors, heureux ? Pas trop déconcerté par tant d’étapes et de tâtonnements pour en arriver là ?  

 


Evidemment, on peut faire plus simple. Suivez le guide en 4 étapes !

1. Vous ne touchez à rien ! Vous êtes dans le cadre d’un ordonnancement aval où la 1ère tâche est planifiée à partir d’une date de début de projet.

2. Vous définissez tâches, liaisons, durées et compétences. Dès lors que la 1ère tâche est créée, elle est planifiée “dès que possible” à partir de la date de début du projet. Si cette tâche est liée à une autre par un lien fin-début, cette dernière s’ordonne juste après. Et ainsi de suite… Vous disposez d’un chemin critique et les tâches non critiques disposent, quant à elle, d’une marge totale bien visible. La durée totale vous permet tout de suite de savoir si vous pouvez caler le projet dans les temps impartis dans des conditions normales et si, en outre, vous disposez d’une marge en fin de projet. Par exemple, votre client vous fixe une échéance au 15 octobre et vous voyez bien que le projet requiert environ 25 jours à compter de la fin août.

3. Si tel n’est pas le cas, il faudra bien adapter les moyens. Vous pouvez maintenir substituer aux compétences des ressources, intégrer les diverses contraintes temporelles, celle de coût,… et visualiser les nouveaux conflits de surutilisation de ressources ou identifier les problèmes d’affectation de ressources sur plusieurs projets ; et résoudre ces conflits.

4. Vérifiez que l’impact de ces résolutions n’empiète pas considérablement sur la marge en fin de projet. Sinon, réajuster le planning en adaptant les moyens.

C’est terminé. De là à dire que, pour faire du retroplanning, il ne faut pas en faire, il n’y a qu’un pas…


J’en viens à me dire que le retroplanning est une vue de l’esprit, au sens littéral du terme. Mon client me demande de caler un planning à partir d’une échéance finale. Mon planning m’indique qu’il me faut 6 mois pour le livrer. Je dispose ou non de ces 6 mois à compter d’aujourd’hui… Faire un retroplanning n’est donc pas nécessaire sauf si on a du temps à perdre ou qu’on veut à tout prix risquer de commettre des erreurs.

Par contre, j’adhère à la réflexion menée à partir d’une échéance finale. On remonte le temps en plaquant une phase de suivi de la mise en oeuvre auprès des utilisateurs, précédée d’une phase de réalisation, précédée elle-même des phases d’initialisation et de conception…

De là à dire qu’il faille délibérément l’appliquer dans le cadre des outils de gestion de projet, c’est une autre affaire.

2 commentaires

  1. bonjour,

    les propos et la démo sont intéressantes. En retroplanning, ce calage au plus tard possible fausse toutes les données encore plus si des taches sont fixées à l’heure. Pour ma part, il me cherche à trouver une date de départ possible, c’est alors que je recale tout par le début (avec les 20% de marge, bien sûr).

    • Oui, sachant qu’il existe également une alternative aux 20% de marge si l’on possède une base de capitalisation des plannings déjà réalisés. En effet, avec 3 plannings similaires réalisés, il est possible d’appliquer la formule du wide band delphi qui nous indique qu’un retard espéré équivaut à un retard pessimiste plus un retard optimiste plus quatre retards attendus (valeur comprise entre l’optimiste et le pessimiste), le tout divisé par six.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée Champs requis marqués avec *

Publier des commentaires

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.