« Quel intérêt de faire un Gantt si c'est pour que dans 3 jours il ne serve déjà plus à rien ? »
C'est la réaction que j'entends le plus souvent quand j'explique qu'on peut obtenir un planning presque automatiquement. Et j'ai du mal à donner tort à ceux qui me la font, parce qu'ils ont souvent vécu la même chose : un planning soigné au lancement, abandonné un mois plus tard.
Sauf qu'à chaque fois que j'ai creusé, j'ai retrouvé le même point de départ : un planning avait été fait, la planification, elle, l'avait jamais été. Les deux mots se ressemblent et on les emploie l'un pour l'autre, alors qu'ils désignent deux choses qui arrivent à deux moments différents du projet
Le planning dit quand, la planification dit pourquoi cette date
Le planning, c'est le document : les tâches posées sur un calendrier, avec leurs dates de début et de fin, leurs jalons et souvent leurs responsables. Le diagramme de Gantt en est la forme la plus répandue, et un tableur avec des cases colorées en est une autre.
La planification, c'est le travail qui permet d'écrire ces dates. On décompose ce que le projet doit produire, on établit ce qui dépend de quoi, on estime les durées avec ceux qui feront le travail, et on en déduit la date à laquelle le projet peut raisonnablement se terminer.
On fait une planification, et on obtient un planning. Le planning répond à « quand ? ». La planification répond à « pourquoi cette date et pas une autre ? »
| Planning | Planification | |
|---|---|---|
| Ce que c'est | Un document | Une démarche |
| La question | Quand chaque tâche a lieu | Ce qu'il faut produire, dans quel ordre, en combien de temps, et ce qui fixe la date de fin |
| Le moment | Après la planification | Avant tout engagement de date |
| Les outils | Diagramme de Gantt, calendrier, tableur | WBS, diagramme de PERT, estimation des durées, chemin critique |
| Quand une tâche glisse | On décale les barres à la main | On recalcule la date à partir des dépendances |
| Qui le fait | Celui qui tient le fichier | Le chef de projet, avec ceux qui feront le travail |
En anglais, planning veut dire planification
Une partie de la confusion vient de l'anglais. Le mot planning y existe bien, sauf qu'il désigne l'action de planifier, c'est-à-dire ce qu'on appelle planification en français. Le document que nous appelons un planning, les anglophones l'appellent un schedule.
Le référentiel du PMI suit cette logique. Dans le PMBOK (6e édition), la gestion des délais enchaîne la définition des activités, leur séquencement et l'estimation de leurs durées, et c'est seulement ensuite qu'un processus élabore l'échéancier (Develop Schedule) à partir de tout ça.
J'ai travaillé à l'Office québécois de la langue française, alors j'ai vérifié : même là-bas, en gestion de projet, le mot planning est admis. Leur fiche le définit, en reprenant l'AFNOR, comme « un document de maîtrise des délais et de communication », et lui donne pour équivalent anglais time schedule. Le planning désigne donc bien le document, et c'est l'anglais qui entretient la confusion.
Un planning sans planification finit refait de zéro
Dans trop d'entreprises, j'ai vu le même scénario. Un diagramme de Gantt construit à la main par le chef de projet, dans son coin, qui a posé les dates, les rôles et réparti la charge pour que tout soit propre sur le slide de la réunion de lancement.
Puis le projet démarre.
On se rend compte qu'une tâche en cachait une autre, qu'une contrainte avait pas été identifiée, qu'on peut pas commencer telle tâche parce qu'on attend une autre équipe, déjà occupée ailleurs.
Tout part en vrille et le Gantt, lui, bouge pas. Au bout de 4 semaines plus personne l'ouvre, et on le refait de zéro à la prochaine réunion
Et c'est normal. Ce planning avait une date pour chaque tâche et aucune raison écrite derrière ces dates : pas de dépendance déclarée, pas de durée estimée par ceux qui font le travail. Au premier écart il y a rien à recalculer, alors on redessine, et c'est exactement ce qui donne raison à la phrase du début.
Un vrai Gantt ne se dessine pas, il naît d'une véritable démarche de planification.
Ce que la planification contient et que le planning ne montre pas
La planification répond à quatre questions, dans cet ordre :
- Qu'est-ce que le projet doit produire ? La WBS décompose le projet en livrables, puis en tâches assez précises pour être estimées.
- Qu'est-ce qui dépend de quoi ? Le diagramme de PERT relie les tâches entre elles : celle-ci peut pas démarrer tant que celle-là est pas terminée.
- Combien de temps prend chaque tâche ? L'estimation se fait avec ceux qui réaliseront le travail, pas à leur place.
- Qu'est-ce qui fixe la date de fin ? Le chemin critique, la plus longue chaîne de tâches dépendantes, donne la durée minimale du projet.
La date de fin vient des dépendances, pas de la somme des durées : deux tâches de dix jours qui peuvent avancer en parallèle font dix jours, pas vingt. C'est seulement une fois ces quatre réponses écrites que le planning peut être posé, et il devient la traduction dans le calendrier d'un raisonnement qui existe ailleurs. Le pas-à-pas complet est dans Comment faire une planification de projet étape par étape.
Quand le PMI interroge les praticiens sur les causes d'échec des projets, trois d'entre elles relèvent directement de la planification : les dépendances entre ressources (26 %), la planification inadéquate (25 %) et l'estimation des durées inadéquate (25 %) (PMI, Pulse of the Profession 2018, 4 455 praticiens, plusieurs réponses possibles). Aucune des trois se corrige en déplaçant les barres d'un Gantt.
Un planning se transmet mal sans sa planification
Il y a une conséquence qu'on voit moins, et qu'on nous a décrite en entretien dans des bureaux d'études. Le planning d'affaire tient dans un fichier Excel, et une seule personne sait le mettre à jour, parce qu'elle seule sait pourquoi telle tâche commence le 12 et pas le 5 : quelle validation on attend, quel lot en bloque un autre, quelle durée a été négociée avec qui.
Le jour où cette personne part, le fichier reste. Les dates sont toujours là, sauf que plus personne sait ce qui les justifie, et à la première modification on découvre qu'on a hérité d'un planning sans la planification qui allait avec
Une planification écrite (le découpage, les dépendances, les durées et leurs hypothèses) se reprend. Un planning seul, on le recommence.
La planification vous donne de quoi défendre une date
Il y a aussi un effet qu'on sous-estime largement. Quand un sponsor ou un client demande « et pourquoi pas deux semaines plus tôt ? », un planning seul a rien à répondre : vous pouvez décaler les barres, et c'est exactement ce qu'on attend de vous.
Avec une planification, vous montrez la chaîne de tâches qui fixe la date, et la discussion change de nature. Pour gagner deux semaines il faut réduire le périmètre, décaler la date ou ajouter des moyens, et c'est à celui qui demande de choisir. La date annoncée est plus seulement la vôtre : elle a été construite avec les équipes, parce que celui qui est sur le terrain voit des risques que vous ne verrez jamais depuis votre planning.
(Alors oui, dans l'idéal on aurait toujours le temps de planifier avant d'annoncer une date. Mais on a tous connu ce sponsor ou ce commercial qui l'a déjà donnée au client avant même que le projet soit découpé)
Dans ce cas la planification sert encore : elle dit si la date tient, et si elle tient pas, ce qu'il faut retirer pour qu'elle tienne. C'est la logique du rétroplanning agile.
Ce qu'il faut retenir
Faites la planification avant de montrer le moindre planning. Un planning qu'on peut expliquer se recalcule quand le projet bouge, un planning qu'on peut pas expliquer se redessine, jusqu'au jour où plus personne l'ouvre. Et vous êtes le premier à y gagner : la prochaine fois qu'on vous demandera de tenir une date, vous aurez autre chose à répondre que oui.
Pour aller plus loin
Chez Orchesia, on est convaincus qu'un planning se déduit du projet au lieu de se dessiner à côté. C'est pour ça que l'outil fait construire la planification d'abord : le découpage dans une carte mentale, les enchaînements dans une vue Dépendances, et le Gantt en est déduit avec son chemin critique. Quand une durée change la date de fin se recalcule, et une baseline garde la date sur laquelle vous vous étiez engagé. C'est ce que fait un logiciel de planification de projet construit dans cet ordre.
