Voici donc la suite de PERT, Gantt et focus en gestion de projet.

Tout d'abord, sachez que j'ai sauté deux chapitres.  Ceux-ci aident à voir le cheminement de la pensée du professeur alors qu'il participe à une conférence portant sur le goulot en production.  J'y reviendrai au besoin.  Revenons maintenant aux 3 éléments qui expliqueraient les retards dans les projets.

Le syndrome de l'étudiant

Peu importe le temps qu'une personne a pour faire une tâche, elle risque d'être en retard.  Pourquoi ?  Parce que les travaux débutent très souvent au dernier moment.  D'ailleurs, plusieurs disent qu'ils travaillent mieux sous pression.  Les premiers jours sont donc perdus inutilement.  Probablement un vestige de nos façons de faire alors que nous étions étudiants.

Impact: toute marge de sécurité ajoutée sera perdue et le projet a de fortes chances de finir plus tard que prévu.

Loi de Parkinson

Une tâche prendra toujours la durée prévue même si le temps nécessaire pour la réaliser est inférieur.  Les gens n'ont habituellement aucun intérêt à finir une tâche plus tôt.  Ça pourrait même être mal vu.  J'ai 3 jours, ça va prendre 3 jours.  J'en ai quatre, alors ce sera 4. 

Impact: tout gain sur une tâche est perdu pour l'ensemble du projet, alors que toute perte se répercute sur l'ensemble du projet.

Multi-tâches

L'utilisation du multi-tâches en entreprise est très valorisée, car il y a plusieurs projets en même temps et cela peut favoriser l'efficacité locale.  Par contre, sur les résultats globaux, c'est autre chose.  D'ailleurs, je vous invite à lire Pourquoi valoriser le multitasking puisqu'il nous rend inefficace ?

Impact: même si certaines tâches seront débutées plus tôt, elles seront toutes livrées plus tard.  Il y a des exceptions, mais si nécessaire, j'ajouterai un diagramme pour illustrer ce propos.

En conclusion

Il ne faut pas se faire d'illusion.  Ces 3 éléments font partie intégrante de nos façons de faire.  On fait tout en même temps, on perd nos marges de sécurité en route et on débute le plus tard possible.  Portrait pessimiste ?

Évidemment, on peut dire que c'est différent en fonction des industries.  Mais est-ce jouer à l'autruche ?

Pour ceux qui sont familiers avec les méthodes agiles, est-ce que celles-ci permettent d'éviter ces 3 écueils ?

Partager/Marquer

Voici la suite de Loi de Murphy et non-performance des projets.

Le professeur demande à un élève de faire un diagramme PERT typique avec estimés.  Voici le résultat:

Le professeur demande alors quel est le chemin critique.  Ce à quoi l'élève répond A+B.  Le professeur rappelle alors la définition:

Le chemin critique détermine le temps que prendra le projet.  Tout délai sur le chemin critique va retarder la complétion du projet.  C'est pourquoi le gestionnaire de projet doit garder le focus sur le chemin critique. 

Dans ce cas, c'est A+B+E.  Le chemin critique est donc de 150 heures.

Les élèves sont d'accord.  Le professeur poursuit en demandant quand les tâches à l'extérieur du chemin critique (C et D) doivent débuter.  S'ensuit une discussion animée.  Voici la première suggestion:

Nous n'avons pas à nous presser pour débuter la tâche C.  Si des coûts sont engendrés, aussi bien attendre le plus possible.  C'est mieux pour l'entreprise.

Il dessine alors son diagramme de Gantt.

L'un des élèves n'est pas d'accord du tout avec ce choix:

Tes projets peuvent bien être en retard.  Tu n'as plus de réserve.  Tu l'as gaspillé.  Pourquoi prendre des risques inutiles ?  Il faut partir le plus tôt possible pour préserver ce temps si précieux.

Il dessine alors son diagramme de Gantt:

Le professeur tente alors de calmer le jeu et définit ce qu'est un diagramme de Gantt:

Les diagrammes de Gantt, contrairement aux diagrammes PERT, incluent des décisions, celles des planificateurs.  Ceux-ci décident quand une tâche débute, où sont les priorités, …

L'un des élèves parle alors d'un problème d'optimisation.  Ce à quoi une élève rétorque qu'il s'agit plutôt d'un problème de gestion.  Elle insiste sur le fait que dans un "vrai" projet, il y a beaucoup plus de ramifications que dans l'exemple simplifié.

Si nous démarrons tout dès le début, le gestionnaire de projet en aura trop sur les mains.  Il va perdre le focus.

D'un autre côté, si nous démarrons tout le plus tard possible, tous les chemins deviennent critiques et nous obtenons le même résultat.

Les discussions continuent.  Un des élèves, qui est aussi auditeur financier, mentionne un point intéressant:

Dès qu'un projet est accepté, il n'y a qu'une chose qui importe.  Si le gestionnaire de projet garde son focus, tous les problèmes seront résolus.  S'il le perd, on peut dire adieu aux bénéfices escomptés et espérer que les pertes ne seront pas trop grandes.

Le professeur ne sait pas vraiment où aller avec ça.  Il tente une nouvelle approche.  Il demande alors à la classe si un mécanisme de contrôle ne pourrait pas aider le gestionnaire de projet à garder le focus: mesurer l'avancement du projet.  Mais l'un des élèves mentionne que ces mécanismes prennent souvent trop de temps à fournir les données.  La discussion est alors orientée sur la façon dont ils mesurent l'avancement dans leurs projets respectifs.

Ces façons de faire sont assez communes.  L'avancement est mesuré en fonction du travail ou de l'investissement réalisé versus celui qu'il reste à faire, avec peu ou pas d'emphase sur le chemin critique.  Le professeur demande l'impact de faire ainsi.  L'un des élèves résume:

Nous encourageons le début de chaque chemin le plus tôt possible.  Le gestionnaire ne peut donc pas garder le focus.  Et cela ne fera qu'empirer par la suite. 

Pourquoi ?  Parce qu'un progrès dans un chemin compense pour un délai dans un autre.  On encourage de progresser rapidement dans un chemin même si ça en retarde un autre.

Un autre élève poursuit:

Qu'est-ce qu'il y a de mal là-dedans ?  Si j'ai de la difficulté dans un chemin, pourquoi ne pourrais-je pas aller dans les autres ?

L'autre reprend:

Parce que les chemins se rejoignent un jour ou l'autre.  Tous les progrès réalisés dans les autres chemins vont devoir attendre pour le chemin en retard de toute façon.

Un gestionnaire de projet avec une vue à court terme peut ignorer les chemins qui sont ralentis par les problèmes.  Les indicateurs vont démontrer que le projet avance.  Le gestionnaire de projet aura l'air en contrôle – pour un temps seulement.  Tôt ou tard, la supercherie fera surface.

Discussion

Qu'en pensez-vous ?  Est-ce que la façon dont on s'y prend pour mesurer l'avancement des projets est adéquate ?  Pensez-vous que cela fausse l'état réel et fait perdre le focus au gestionnaire de projet ?

La suite dans les prochains jours.

Partager/Marquer

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.

Partager/Marquer

Voici donc la suite de Pourquoi certains projets échouent et d'autres non ? dans le cadre de l'analyse du livre Critical Chain de Eliyahu Goldratt.  À mon sens, le chapitre aborde 2 thèmes.  Bien qu'il y ait un lien, je vais les séparer.  Voici la première partie.

Constats d'un projet qui a échoué

Le professeur sélectionne l'un des projets des étudiants et entreprend l'analyse.  Il s'agit d'un projet de construction d'usine en Malaysie avec un retard de 8 mois. 

Voici la liste des raisons officielles de la haute direction:

1. Météo particulièrement mauvaise qui a retardé la construction
2. Difficultés impossibles à prévoir rencontrées par les vendeurs qui fournissaient les machines
3. Négociations plus longues que prévues avec le gouvernement Malaysien pour les termes au niveau de l'emploi

Et voici la liste des raisons non officielles du gestionnaire de projet:

1. La compagnie a forcé un calendrier irréaliste dès le début
2. Le choix des vendeurs les moins chers était dicté à l'avance, même en sachant qu'ils sont moins fiables sur la livraison
3. Même en répétant régulièrement les avertissements, les efforts pour recruter et former le personnel de l'usine et les travailleurs ont été fait trop tard

Et finalement, la liste des raisons non officielles des gens travaillant avec le gestionnaire de projet:

1. On se fiait trop sur les rapports d'avancement des vendeurs qui étaient trop optimistes
2. Pas assez de supervision pour les entrepreneurs malaysiens
3. L'équipe de projet passait constamment d'un feu à un autre et était débordé
4. Beaucoup trop de réunions de synchronisation inutiles qui interrompaient le travail

Les 2 constats sont:

• C'est toujours la faute des autres: la température, les vendeurs, le gouvernement Malaysien.
• Plus on est bas dans la hiérarchie, plus le problème est les gens pointent à l'intérieur de la compagnie.  Plus on est haut, plus il est les gens pointent à l'extérieur de la compagnie.

En tenant compte de l'avis des gestionnaires de bas niveau, la conclusion est que les projets auraient pu être mieux gérés. 

En tenant compte de l'avis de la haute direction, la conclusion est que cette mauvaise gestion est due à l'incertitude – qui fait partie de tous projets.

La discussion continue: pourquoi ne pas tenir compte de cette incertitude dans la planification ?

Réflexion

J'arrête ici et j'attends vos commentaires.  La suite portera sur le temps estimé d'une tâche.

Qu'en pensez-vous ?  Ça ressemble à ce que vous avez vécu ?  Pour rendre la suite intéressante et faire des liens avec le livre, votre interaction est nécessaire.  Merci de prendre le temps de partager avec tous.

Source de l'image: Microsoft Online Clipart

Partager/Marquer

MAJ 2010-01-27 Pour ceux qui cherchent uniquement une liste de raisons pour les échecs de projet, je vous invite à aller à la fin de l'article pour la suggestion d'un Top 10 des raisons pourquoi certains projets échouent.

Mise en contexte

Une compagnie produit des modems.  Ils sont cotées en Bourse et doivent continuellement montrer une croissance.  Le temps nécessaire pour créer un nouveau produit est long (plus qu'un an), alors que chaque nouveau produit doit être lancé régulièrement (moins qu'un an).  C'est une situation très stressante et dangereuse. 

Le vice-président de la compagnie réunit une équipe de 3 personnes relativement jeunes (début trentaine) pour trouver une solution "out-of-the-box".  Ils s'inscrivent à un EMBA et participent à un cours sur la gestion de projet.  Le professeur a un style très ouvert qui se rapproche de la formule des barcamps.

Premier cours

Après une définition sommaire de la gestion de projet, ils discutent des problèmes vécus dans leurs propres entreprises.  La question posée est: Pourquoi certains échouent et d'autres non ?  Qu'est-ce qui est commun ?

La conclusion du premier cours est:

Les problèmes communs de tous les projets, peu importe l'industrie, sont une haute probabilité de:

• dépassement des coûts
• retards sur les échéanciers
• un contenu incomplet

Leur premier devoir consiste à:

• sélectionner un projet dans leur compagnie respective qui vient d'être terminé ou qui le sera très prochainement
• effectuer des entrevues avec ceux qui ont effectué le travail et une avec le supérieur du gestionnaire de projet
• préparer 2 listes: une avec les raisons officielles et une avec les raisons non officielles des résultats obtenus

Prochain article

D'ici le prochain article, que diriez-vous d'essayer d'effectuer le même travail ?  Il serait intéressant de comparer leurs résultats aux vôtres.  Qui veut relever le défi ?

Évidemment, pour ceux qui venaient chercher la réponse à la question du titre, elle se trouvera peut-être dans les prochains articles de la série Critical Chain

MAJ 2010-01-27

Top 10 des raisons pourquoi les projets échouent (suggestion)

En attendant, voici quand même (en anglais)  le Top 10 des raisons pourquoi les projets échouent selon Anish Mathai Mathew (discussion LinkedIn ici):

1. Lacking Sponsor's Involvement/Ownership 
   
2. Halo Effect (Wrong Man for the Job) 
   
3. Poor HR Management 
   
4. Poor/Inadequate Project Communications 
   
5. Ignoring Project Stakeholders 
   
6. Absence of Risk Management 
   
7. Scope Creep/Unrealistic Expectations 
   
8. Lack of Monitoring of Plan 
   
9. Absence of a Project Management Methodology 
   
10. Simple BAD LUCK
    

Il n'y a pas d'ordre dans le Top 10.  Qu'en pensez-vous ?

Partager/Marquer