En gestion de projet, il arrive parfois un phénomène rare et tenu secret : des projets se terminant à l’heure.
Attention, ici nous parlons bien des projets qui se terminent à l’heure par rapport à leur date initiale prévue. Nous n’évoquerons pas les projets qui sont finis à l’heure par rapport à la dernière date…mise à jour !
Mais il existe parfois de sociétés qui sont capables de terminer tous les projets dans les temps ! Ce phénomène en gestion de projet est une déviante de la Loi de Parkinson.
La Loi de Parkinson consiste à toujours consommer la durée évaluée au moment de l’estimation de la tâche. Par exemple, une personne donne une durée de 5 jours. La personne a quasiment terminé au bout de 2 jours, mais elle va passer les 3 jours restants à peaufiner la tâche pour respecter la durée impartie ! Pourquoi ?!
Pour deux raisons :
- Si elle dit qu’elle a terminé plus tôt, il est probable que la fois suivante, son temps alloué lui sera réduit.
- Quand bien même, elle dirait avoir terminé plus tôt, la ressource suivante est occupée à faire autre chose. Donc cette dernière n’est pas disponible pour prendre le relais. Ainsi le temps gagné par la ressource est perdu dans la file d’attente du responsable de la tâche suivante.
Lorsque l’on met en place notre approche de Management de Projet par le FLUX, nous utilisons un indicateur qui s’appelle le Fever Chart.
Il consiste à regarder l’avancement du projet par rapport au buffer qui le protège.
Dans l’exemple ci-après, remarquez-vous quelque chose d’étonnant ?
1/ Oui, le projet s’est terminé pile à l’heure !
2/ Oui, la fin du projet s’est faite d’un coup sec.
3/ Oui, vous avez bien remarqué que la très forte majorité des points de revue du projet sont :
- Majoritairement dans la zone jaune ;
- Fleurte entre le jaune et le rouge très souvent ;
- Ou dès qu’ils vont un peu trop dans le rouge, ils reviennent quasiment le coup d’après dans la zone jaune.
Vous avez ici une bonne illustration de la Loi de Parkinson. L’équipe, dès qu’elle est dans le rouge a la capacité de revenir en mode « normal », et l’équipe semble être en mesure d’adapter sa vitesse d’exécution en fonction du statut de consommation du buffer.
En admettant que ce cas particulier soit généralisé à l’ensemble du portefeuille projet de cette société, que pourrions-nous proposer ?
Nous pourrions suggérer de réduire la durée des tâches jusqu’à ces phénomènes se produisent de manière moins récurrentes.
Ainsi si l’équipe est capable d’accélérer, décélérer, on peut être en mesure de voir jusqu’où ces phénomènes peuvent absorber les variations de leur projet.
Par exemple, on voit qu’entre 10% et 40% d’avancement de projet, le projet reste étonnamment dans le jaune et qu’il fleurte entre le jaune et le rouge entre 45% et 60% d’avancement.
En conclusion faire plus vite pour faire plus vite représente un gain assez local.
Dans la mesure où ce cas serait généralisable et que vous puissiez réduire la durée de vos projets, il conviendra au préalable de se poser la question suivante : Quels sont les bénéfices pour ma société et mon marché à terminer encore plus rapidement mes projets ?