Résumé de « De la performance à l’excellence »

Le but de la recherche entamée par l’équipe de Jim Collins était de répondre aux questions suivantes:

Qu’est-ce qui fait qu’une entreprise passe du jour au lendemain de moyenne à excellente ? Que font-elles de différent ? Peut-on les imiter ?

Chacun des chapitres est en soit une partie de la réponse. Chacun des billets de cette série reprendra l’essentiel de ceux-ci.

Avant de parler du premier chapitre, je tiens à mentionner que le schéma utilisé pour illustrer ce passage (de bon à excellent) m’a tout de suite fait penser à celui utilisé dans le livre de Malcolm Gladwell intitulé Le point de bascule. Donc, une fois cette série de billets complétés, je pourrai tenter de faire des rapprochements avec cet autre livre. Si vous pensez également à d’autres liens intéressants, faites-moi en part.

Note: Ce texte a été publié précédemment sur un autre de mes blogues que je désire fermer.

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 ?

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.

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.

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

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 ?

Si des personnes utilisent cette méthode dans les leurs projets ou entreprises, j'aimerais éventuellement faire une entrevue avec vous pour le bénéfice de tous.  L'invitation est lancée.

Les dirigeants de Protrain Canada se positionnent comme innovateurs en formation reliée à la gestion de projet.  Je suis d’accord avec eux et c’est pourquoi je les ai sélectionnés comme partenaires.  Ils sortent des sentiers battus à plusieurs niveaux.  C’est rafraîchissant.  J’ai donc vu d’un bon oeil cette formation sur l’intuition.  Un complément à notre société très analytique.  Jusque là, tout va bien.

Madame Tesolin a bien animé la rencontre et a donné des exemples pertinents tout au long de son exposé.  Les exercices étaient intéressants, particulièrement ceux permettant de déterminer où nous nous situons.  Donc rien à dire à ce niveau.  J’ai beaucoup apprécié.

Nous étions 12 personnes, majoritairement des femmes (si je m’exclus ainsi que les 2 organisateurs).  Une fois la gêne tombée, je crois qu’on peut dire qu’il régnait une bonne atmosphère d’échange.  Quelques fois seulement, j’ai senti certaines personnes décrocher d’un exercice, surtout vers la fin.  Mais encore là, c’était bien.

Alors c’est quoi le problème Mathieu ?

J’ai senti (compris ?) que le développement de l’intuition doit se faire sur une base personnelle et individuelle.  Le faire en groupe vient troubler en quelque sorte l’état d’esprit requis pour une telle démarche.  Aussi, je crois que ce serait mieux sur une plus longue période, un peu comme elle le décrit dans son livre Ting!  On fait une première partie, on expérimente, puis on découvre des choses, puis une deuxième partie, etc.

Je constate donc que le développement de l’intuition en affaires n’est pas une sinécure.

Voici quand même certains éléments qui sont ressortis dans la journée et que je trouve pertinent de lister ici:

• Think out of the box: La boîte est un modèle mental développé pour schématiser un processus.  Nous pensons que nous devons constamment traiter ce qui rentre.  Cette façon de penser doit être brisée.
• Nous utilisons l’intuition lorsque nous n’avons plus de repères, particulièrement en période d’urgence ou de stress.  Cela pourrait être plus souvent.
• Les gens très intuitifs sont souvent étiquetés comme de bons analystes, mais ils ne font que confirmer leur intuition avec les données.
• En gestion de projet, nous devons souvent prendre des décisions alors que nous n’avons pas toutes les données.  C’est là que l’intuition – et l’expérience – entre en jeu.

En toute transparence, j’espère que les participants ont apprécié leur expérience et j’espère que Protrain Canada trouvera une autre façon d’aborder le sujet.  Sans rancune.

• An Excerpt from Ting!
• Don’t Stifle Intuition in Your Workplace
• Why Intuition is Winning New Respect As a Smart Business
• Using Intuition to Make Management Decisions

Je crois personnellement qu’il est bien de savoir utiliser plusieurs sources d’informations, selon l’occasion et ce qui est disponible.  Je ne crois pas qu’il y ait une bonne et une mauvaise façon de prendre ces décisions.  Elles sont complémentaires. Et vous, utilisez-vous l’intuition pour prendre vos décisions d’affaires ?  Et si oui, comment se manifeste cette petite voix intérieure ?

NASA Leadership failure

Comme mentionné précédemment dans How NASA Builds Teams et Le contexte social: élément clé de la performance, une conférence aura lieu prochainement.  De quoi parlera-t-on ?  Notamment d’échecs, et pas n’importe lesquels: ceux qui sont médiatisés.  Imaginez que votre projet se retrouve sur la page couverture de tous les journaux et magazines, que les gens en parlent à la télévision et dans la rue.  Seriez-vous assez fort mentalement pour prendre cette pression ?

C’est ce qui est arrivé à la NASA.  Si on se souvient bien, il y a eu l’accident de Challenger en 1986.

Ensuite, il y a eu le lancement du téléscope Hubble qui était également prévu cette même année (1986), mais qui fut retardé jusqu’en 1990 pour des raisons évidentes.  Ce qui était supposé redorer la NASA a été finalement une énorme déception.  Les images étaient floues.

Diagnostic docteur ?  Leadership failure.

Ouch!  Ça, ça fait mal.  Il y a un remède ?

Charles Pellerin, auteur du livre How NASA Builds Teams, mentionne dans son livre que cet événement a changé sa vie.  Il a quitté son poste (directeur astrophysique) et a entrepris ce projet un peu fou.  Comment améliorer le contexte social et comment faire pour informer et former les gens « logique », c’est-à-dire les ingénieurs, scientifiques, etc.   Ceux qui ne veulent rien savoir du « touchy-feely ».

C’est ainsi qu’il a mis en place la méthodologie 4-D, basée sur 4 dimensions et 8 comportements à mesurer.  En lisant le livre, j’ai revu mes 10 dernières années professionnelles.  J’ai compris mon cheminement.  J’ai compris mes succès et mes échecs.  Je voulais en savoir plus.

Comment ça s’applique dans le réel au sein des équipes ?  Je n’en ai aucune idée.  Mais j’ai déjà hâte à la section atelier du 6 novembre 2009.