Gestion de projet

On désigne ainsi les différentes formes de contraintes de date qui peuvent concerner certaines tâches d'un projet.

On trouve les quatre formes classiques suivantes :

• Début pas avant le (début au plus tôt le)

• Début pas après le (début au plus tard le)

• Fin pas avant le (fin au plus tôt le)

• Fin pas après le (fin au plus tard le)

La première et la dernière sont les plus couramment utilisées.

Il est fondamental que les dates imposées apparaissent sur le diagramme PERT car elles ont un impact immédiat sur les dates calculées et les marges. Leur absence compliquerait sérieusement la lecture et la compréhension du planning.

On les représente avec des petits drapeaux dans lesquels la date imposée est inscrite.

Pour les dates imposées de la catégorie "pas avant le", le mât du drapeau est à gauche, pour les autres il est à droite. Le mât du drapeau peut ainsi être vu comme la limite à ne pas dépasser pour les calculs de dates. Le mât est à gauche comme la limite inférieure (" pas avant le ") et à droite comme limite supérieure (" pas après le ").

Pour les dates imposées de la catégorie "début" le drapeau est juste à droite de l'étape début et à gauche du libellé, pour celles de la catégorie "fin" il prend place juste à gauche de l'étape fin, à droite du libellé de la tâche.

En toute logique, on devrait trouver une date imposée sur chaque tâche sans prédécesseur (pour fixer sa date de début au plus tôt) et sur chaque tâche sans successeur (pour fixer sa date au plus tard).

On l'a déjà vu, l'estimation des durées des tâches est un exercice délicat.

A partir du moment où des durées sont déterminées, il est important qu'elles apparaissent clairement sur le graphe PERT (pour rappel, celui-ci est totalement dépourvu d'échelle de temps) pour la compréhension du planning et son analyse si un travail sur le délai global du projet est nécessaire.

A l'époque où les graphes étaient produits à la main, on pouvait garder l'historique de l'évolution des estimations des durées des tâches, mais je ne connais pas d'outil de tracé capable de le proposer aujourd'hui.

Il est pratique de disposer d'un outil qui accepte différentes unités pour l'expression des durées car il est fréquent que des durées sont exprimées en heures (H), demi-journées (D), jours (J), semaines (S) ou mois (M) dans le même planning.

Si le planning n'est pas rédigé en français, l'outil doit pouvoir accepter n'importe quel code unité durée en référence à une table de correspondance interne.

Dans un outil de planification de projets, un calendrier permet de définir, sur l'étendue du projet, une séquence particulière de périodes oeuvrées et de périodes chômées.

Les calendriers sont très pratiques et permettent de simuler des tâches qui ne peuvent se réaliser qu'à des moments précis (départs de bateaux ou de fusées, périodes budgétaires, maintenance en période creuse, barrières de dégel, etc.). Ainsi, le calendrier civil de chaque pays avec ses dates de WE et ses jours fériés doit être pris en compte dans tout projet international. Et un sous-traitant français qui baisse le rideau chaque année du 14 juillet au 15 août doit avoir ses tâches dotées d'un calendrier qui reflète cette réalité, sinon le planning est faux !

Chaque tâche est ainsi affectée à un calendrier.

Pour le logiciel de tracé de plannings PERT, la mention du calendrier de chaque tâche sur le graphique est presque aussi indispensable que sa durée. En effet, s'ils sont plusieurs sur un même projet, l'impact des calendriers sur les résultats des calculs des dates est immédiat et, souvent, l'explication des dates et marges affichées pour la réalisation de certaines tâches doit faire appel aux calendriers.

Les tâches fictives possèdent aussi un calendrier. On leur affecte un calendrier sans aucune période chômée (dit "constant") pour être assuré qu'elles ne perturberont pas les calculs en imposant des temps morts inutiles, en particulier si elles relient entre elles des tâches affectées elles-mêmes à des calendrier différents entre eux. Le calendrier des tâches fictives n'a pas besoin d'être visible sur les graphes.

Lors de l'enregistrement régulier de l'avancement du projet et de la mise à jour d'un planning, il est bienvenu que certaines tâches du projet soient annoncées terminées.

Les tâches enregistrées terminées reçoivent également une date imposée du style "terminé le", ce qui permet au calcul de la replanification de les ignorer.

Pour la planification et le pilotage du projet, l'enregistrement de la date réelle d'achèvement d'une tâche est sans intérêt, ce qui compte c'est bien qu'elle puisse être considérée comme totalement achevée au jour de la revue du planning (sinon elle serait encore en cours et sa durée devrait en conséquence être réestimée pour qu'elle influence la date de début de ses successeurs !).

Pour la représentation graphique, une méthode simple consiste à tracer chaque tâche terminée avec un trait épais et de placer sur sa droite un drapeau avec la date du constat d'achèvement. La date du constat d'achèvement n'est pas la date exacte à laquelle la tâche a pris fin qu'il n'est pas utile de connaître ici, mais bien la date de la revue au cours de laquelle il est acté entre le chef de projet et le responsable de la tâche que la tâche passe au statut "terminée".

Remarque : enregistrer la date de fin réelle d'une tâche terminée aurait pour conséquence désagréable de faire "planifier le passé", au moins sur la période écoulée depuis cette date de fin. Autant mettre tous les compteurs à zéro, considérer de la même façon (i.e. les ignorer) toutes les tâches déjà terminées et recalculer le planning comme si la date de début était le jour de la revue après avoir pris soin d'actualiser les durées des tâches en cours ou assimilées.