Le rétroplanning tient-t-il toutes ses promesses ?

Vous réalisez des retroplannings ? Alors, allez-vous jusqu’au bout de la démarche et votre retroplanning tient-t-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é, le rétroplanning tient-t-il ses promesses ?

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 œuvre aussitôt ? Est-il retraité pour être exploitable ?

Les étapes à franchir

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 dispose d’une contrainte de date « le plus tard possible » et se planifie à partir de l’échéance finale. Si cette tâche dispose d’un prédécesseur, ce dernier s’ordonne juste avant. Et ainsi de suite… Comme tout s’ordonne 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 vous basculez sur un ordonnancement aval, vous modifiez la contraintes de date des tâches récapitulatives. Elles affichent désormais « dès que possible ». Mais vous ne modifiez pas la contrainte de date des tâches qui demeurent « le plus tard possible. »

4. Prenez votre courage à deux mains !

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. De surcroit, 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

Ceci 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. Intégrez les contraintes

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à ? Vous voyez que le retroplanning tient toutes ses promesses ! 

Evidemment, on peut faire plus simple pour que le retroplanning tienne ses promesses

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…

Dès lors, 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…

Le retroplanning ne tient décidément pas toutes ses promesses.

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.