Si la non-performance des projets est due à l’incertitude inhérente des tâches qui les composent, pourquoi ne pas en tenir compte dans l’estimé initial ? C’est souvent l’une des raisons pourquoi les dirigeants n’aiment pas inclure trop de personnes dans la planification d’un projet. Le temps requis pour réaliser le projet devient souvent 2 et 3 fois plus important que ce que le client peut accepter. Et il faut vendre n’est-ce-pas ?
Voici donc la suite de Échec de projet – c’est toujours la faute des autres.
Pourquoi ne pas tenir compte de cette incertitude à la planification ?
La discussion continue avec le professeur. La réponse des étudiants est très claire à ce sujet:
La haute direction ne nous le permet pas. Mon projet estimé à 30 mois a été restreint à moins de 24 mois par mon supérieur, ce qui est impossible.
Le professeur fait remarquer qu’il s’agit de 20% de la durée et questionne l’étudiant si c’est assez selon lui comme marge de sécurité. Celui-ci répond que non, mais même celle-ci n’est pas acceptée. Le professeur distingue alors la sécurité du projet versus la sécurité d’une tâche.
Combien de temps dure une tâche ?
Le professeur dessine une distribution gaussienne et parle de probabilité. Lorsqu’il demande à l’un de ses étudiants combien de sécurité est incluse à même la durée d’une tâche, celui-ci mentionne aucune : les estimés sont les plus réalistes que possibles. Insatisfait de cette réponse, le professeur tente de faire une comparaison avec une situation de tous les jours. Il demande combien de temps est nécessaire pour aller de la maison à l’Université. Voici la réponse obtenue:
Environ 25 minutes. C’est-à-dire :
- Selon les conditions routières
- Selon le trafic,
- Selon s’il y a des arrêts à faire en cours de route
- Selon les imprévus (panne, crevaison, …)
- Selon le respect du code de la route
- …
Le professeur dessine alors une nouvelle distribution :
et il continue:
Voici ce à quoi ressemble la probabilité de terminer une tâche. Plus il y a d’incertitude, plus la courbe sera étirée vers la fin. La médiane est à 50%, c’est-à-dire qu’il y a 50% de chance que la tâche soit terminée à cet instant.
Lorsque vous donnez un estimé, vous indiquez souvent 80% et même 90% parfois.
Ce à quoi un élève répond que Murphy existe. Personne ne serait assez suicidaire pour choisir la médiane. Le professeur rétorque :
Cela fait du sens en effet. Dans la plupart des environnements, rien n’incite les gens à terminer avant la date prévue, mais il y a toujours des raisons d’être en retard.
La différence entre ces 2 lignes est la sécurité incluse dans chaque tâche. Donc, étant donné Murphy – l’incertitude – la sécurité incluse semble plutôt de l’ordre de 200%.
Le professeur résumé le cours et donne un nouveau devoir :
Retournez à votre projet et choisissez au hasard 3 tâches différentes. Déterminez pour chacune d’entre elles comment elles ont été estimées.
Suite au cours, une discussion a lieu entre 3 collègues :
Les gens donnent leurs estimés réalistes basés sur leurs pires expériences.
Discussion
Est-ce que cela ressemble à la façon dont vous fonctionnez à votre travail ? Est-ce que cela vous amène à vous questionner sur vos méthodes ? J’ai hâte de lire vos commentaires et de vous résumer le prochain chapitre.
Pingback: uberVU - social comments
Bonjour,
Pour résoudre le problème d'estimation des tâches soulevé dans cet article, il peut s'avérer utile de joindre un simple principe de gestion des risques. Ainsi, à chaque tâche, on indique deux estimations: le temps (ou le coût) requis dans le meilleur des cas (T_MIN) et le temps requis dans le pire scénario (T_MAX).
Par la suite, encore une fois pour chaque tâche, on identifie le pourcentage (0 à 100%) de risque (%_RISK) que cette tâche rencontre le pire scénario. Idéalement, cette évaluation des risques peut être réalisée par un tiers ou en comité d'experts.
L'évaluation finale de la tâche = T_MIN + (T_MAX – T_MIN) * %_RISK
Cette méthode bien simple a tendance a minimiser les problèmes d'évaluation évoqués dans cet article.
Roger Mathieu, La Société conseil Lambda
Tout d’abord, bienvenue. Je crois qu’il s’agit de votre premier commentaire sur LaGestionDeProjet.com et je vous en remercie.
En effet, cela semble être une bonne façon d’inclure le risque à même la durée de la tâche. Merci de nous la partager.
Au niveau du livre, nous verrons qu’ils préconiseront d’utiliser en tout temps la médiane. Cela fait partie de la méthodologie Chaîne critique. Les autres éléments de celles-ci suivront dans les prochains articles.
Par expérience, je pense que les freins le plus important à vaincre sont les manques de transparence et d' honnêteté intellectuelle.
En effet, cette pratique suppose, pour intégrer la notion d'incertitude propre à tous les projets, la mise place de "réserves" de temps pour protéger les branches critiques d'un projet.
Or la durée de vie de ces réserves, quelque soit le nom qu'on leur donne, est souvent très courte.
Le scénario est toujours le même.
Le CP estime 80 en typique mais 100 au pire, donc annonce 100. S'il joue le jeu de la transparence, les chiffres retenus seront 80 et 20 de réserve au cas ou…
La négociation étant difficile, il faut réduire le devis à 80 pour obtenir la commande.
Le projet se déroule donc avec une forte pression pour tenir les 80.
La modification de la priorité des urgences s'en mêlant, le projet se termine malheureusement à 90.
Bilan : deux insatisfaits. La société qui à perdu 10, le CP qui n'a pas tenu ses objectifs.
Conclusion : Le CP jura mais un peu tard que l'on ne l'y prendrai plus.
Associée à cette pratique, il existe sans doute une méthode de gestion de projet, réservée au management supérieur,
ou l'on mette en exergue le support effectif a apporter au CP pour lui permettre de tenir ses objectifs.
Qu'en pensez-vous ?
Merci Michel pour ton commentaire. Ton exemple illustre bien la réalité que vivent plusieurs chefs de projet. Ça me rappelle justement un collègue qui gardait pour lui seulement la dite réserve.
L’un des points soulevés par l’auteur, c’est que chaque personne ajoute sa propre réserve, mais à sens unique. C’est-à-dire que s’ils en ont besoin, ils la prennent, sinon ils la gaspillent. Personne n’est félicité s’il termine plus rapidement. C’est même mal vu parfois; ça voudrait dire qu’on a menti ou qu’on s’est protégé.
Concernant ton dernier point – méthode de gestion de projet – je ne pense pas qu’il existe UNE méthode de gestion de projet. Chaque entreprise a probablement la sienne, un mélange de pressions internes et externes. Il existe bien des bureaux de projets (PMO), mais il y a beaucoup de différences entre chacun.
Le prochain billet portera sur PERT, GANTT et focus en gestion de projet.
Bonjour,
Par rapport à votre démarche de prendre toujours la médiane, comment mettez-vous en relation la prioritisation de ces tâches ? Car pour la même tâche je peux avoir deux estimations différentes.
Je prend un exemple, lors d'un développement informatique. Si des tâches se succèdent dans le même environnement, le temps de mise en train sera très court tandis qu'il sera plus long si je dois changer de système de développement.
La succession de tâches peut être modifié par une priorité qui change souvent, donc une durée de tâche qui change.
Dois-je intégrer dans la durée de ma tâche ce facteur ? Ai-je d'autres solutions ?
Merci
@boubo5
Je tiens à préciser qu’il s’agit de la démarche préconisée par la chaîne critique, pas nécessairement par moi. Je donnerai mes impressions à la toute fin de la série d’articles.
Ceci étant dit, l’utilisation de cette démarche nécessite d’autres éléments qui seront présentés dans les prochains billets. L’utilisation de la chaîne critique est un tout – en utiliser simplement une partie n’apportera pas vraiment de gains. Par exemple, il ne faut pas utiliser de multi-tasking. Il faut aussi anticiper le départ de la nouvelle tâche. En fait, il faut en tout temps démarrer une tâche dès que tous les prérequis sont réunis et la compléter le plus tôt possible.
Le problème auquel vous faites face – changement de priorité régulièrement – vient souvent du multi-tasking. On éteint des feux continuellement. C’est évidemment une réponse partielle qui trouvera écho très prochainement.
Les chances de ne pas avoir bien répondu à votre question sont quand même élevées, alors n’hésitez pas à clarifier (je fais référence au changement de système de développement – je n’ai pas saisi les raisons d’un changement en cours de route).
Bonjour,
Vous avez raison, c'est de cette manière que mes chefs travaillent. Ils n'arrivent pas à être pro-actif sur les différents projets et ensuite on fait du travail rapide comme des pompiers et comme l'environnement n'est pas homogène, on doit changer d'outils règulièrement . C'est un peu comme dans le domaine automobile, vous avez beaucoup d'électronique dans des voitures alors que des voitures anciennes n'en contiennent pas.
Pingback: PERT, Gantt et focus en gestion de projet