Lors de la dernière saison, vous aviez découvert les différentes manières dont pouvait être analysé un Fever Chart. Il est temps d’attaquer la saison 2 dont le thème sera l’utilisation du plan de projet.
Dans cet article, nous décrirons :
- ce qu’est un plan de projet,
- pourquoi on le fait,
- les gains
- et les risques associés à ne pas l’avoir.
Dans les articles suivants, nous aurons l’occasion de clarifier :
– comment découper un projet,
– à quel niveau de granulométrie il faut aller,
– comment réduire la durée du projet
– et enfin, l’éternel débat autour de la charge/capacité des ressources dans les outils de gestion de projet.
Mais d’abord, qu’est-ce qu’un plan de projet ?
Si vous n’êtes pas toujours d’accord sur ce que cela veut dire concrètement quand votre projet est fait. Ou s’il vous manque des données d’entrées pour démarrer certaines tâches alors que les équipes en amont sont persuadés d’avoir terminé correctement leur travail… C’est que votre plan de projet est défectueux !
Le plan de projet est la représentation schématique des liens logiques entre les différentes étapes du projet. Il est tracé de la gauche vers la droite pour représenter la chronologie du projet (Source PMI, Project Schedule Network Diagram).
Là où le WBS (Work Breakdown Structure) s’évertue à clarifier la nomenclature du projet, le plan de projet (Network Diagram) cherche à établir la gamme et donc la relation entre les tâches.
Pour reprendre une analogie présente sur le web, il s’agit de l’histoire du professeur de philosophie qui remplit une jarre de cailloux devant ses élèves. Lorsque la jarre est pleine de gros cailloux, il demande à son auditoire si la jarre est pleine. Ce à quoi les élèves confirment. Puis le professeur prend des graviers et vient remplir la jarre avec. Etc.
Le principe de construction est exactement le même.
Au point le plus haut, on va identifier le nom du projet ainsi que les livrables et données d’entrées nécessaires. Pour cela, deux questions vont nous guider :
- Qu’est-ce que cela veut dire quand c’est fait ?
- De quoi a-t-on besoin pour démarrer ce projet/tâche ?
Lorsque cette étape est réalisée, nous allons chercher à identifier les grandes étapes de ce projet (pas nécessairement des jalons). La question que l’on pose souvent à nos clients est la suivante :
Comment me résumeriez vous votre projet en 3 à 5 idées ?
Pour chacune des idées identifiées, nous allons poser les deux premières questions, afin de clarifier les livrables et les données d’entrées nécessaires pour réaliser ces étapes. Ensuite, il faudra :
- Créer les liens entre ces étapes
- Détailler chacune de ces étapes avec la question 3, puis la clarification des livrables et données d’entrées.
Lorsque ce processus est fait, il se peut que la création des liens révèle plusieurs cas :
- Un livrable n’est pas relié à une donnée d’entrée d’une autre tâche : dans ce cas, la question consiste à déterminer la pertinence de ce livrable. Si la pertinence est réelle, cela vous indique qu’il manque des tâches pour compléter le Network Diagram.
- La donnée d’entrée n’est pas un livrable en amont : le raisonnement est exactement le même mais dans l’autre sens 😉.
Lorsque vous aurez fini, vous obtiendrez quelque chose qui ressemblera à cela :
A la fin de ce processus, vous pourrez identifier les compétences nécessaires pour chacune des tâches ainsi que la durée estimée associée. Il ne s’agit pas ici de rentrer dans un débat sur l’estimation des tâches mais, si vous connaissez notre approche, vous savez qu’il vaut mieux saisir des durées sécurisées afin d’exploiter ces marges d’une manière différente.
Vous avez pu remarquer que ce processus est itératif. Le corollaire est donc à quel moment dois-je arrêter de faire des itérations ? Lorsque mes projets sont très longs, comment dois-je faire pour piloter un projet de plusieurs années ? Etc…
La question qui émerge donc est : Jusqu’à quel niveau de détail dois-je aller dans la définition de mes tâches ?
La suite à l’épisode 2…
Ps : Vous trouverez ci-après un lien qui détaille l’ensemble de ce processus. Il a été écrit par Mrs Austin et est, à mon sens, la meilleure description de ce qu’est un Network Diagram.