Top 10 Myths in Project Management

billet original de Philip R. Diab http://philipdiab.com/2010/11/myths/

Si je jette un coup d’œil en arrière vers le début des années 1990, beaucoup de collègues avaient l’habitude de dire que le management de projet est le meilleur secret caché du business.

L’idée très répandue que le management de projet n’était pas une profession principale et souffrait donc d’un manque de conscience de son rôle essentiel était, en un sens, une épée à double tranchant. Ceux qui étaient bien versés dans la pratique de management de projet avaient acquis une très grande valeur dans les organisations. D’un autre coté, convaincre les organisations qu’elles avaient besoin de praticiens du management de projet restait un challenge. Ce paradoxe aidant, beaucoup de mythes se sont formés dans la communauté business sur ce qu’est le management de projet et ce qu’il offre aux organisations. En outre, le rôle du chef de projet était un peu flou.

Si nous devions chercher la définition du mot mythe, nous constaterions qu’une définition est qu’un mythe est “une croyance ou une idée largement répandue, mais fausse.”

À bien des égards un mythe dans ce contexte est très proche d’une mauvaise assomption. Le PMBOK® Guide définit des assomptions comme “des éléments que, dans un objectif de planification, l’on considère comme étant vrais, réels, ou certains sans preuve ni démonstration.” Autrement dit, si vous savez qu’une croyance est fausse, alors ce n’est plus une assomption. De même, si vous savez que quelque chose est vérifiable alors ce n’est plus une assomption, mais un fait.

De façon assez intéressante, j’ai cependant observé que beaucoup de praticiens et de parties prenantes essayent néanmoins de documenter des assomptions dont ils savent qu’elles sont probablement fausses. Un de mes exemples préférés est quand l’équipe inclut une supposition qui dit “la direction de la société supporte ce projet.” Je suggérerais que ce type de supposition est vraiment trop dangereux car il fait porter à l’équipe une quantité significative de risque. Il est important de comprendre que pour chaque assomption, nous allons probablement rencontrer un risque auquel on devra s’attaquer.

Cependant, au-delà des projets individuels et de leurs assomptions, j’ai aussi rencontré par hasard beaucoup de situations et de personnes qui avaient des vues étranges quant au management de projet. À bien des égards j’en suis venu à considérer ces vues comme des mythes car elles ont souvent très peu à faire avec la réalité du management de projet.

Voici mes 10 mythes préférés:

1. les faits et les chiffres sont plus importants que les sentiments et les perceptions.

Bien que les faits soient très importants, je vois souvent des projets dérailler et être sabotés à cause de fausses perceptions. Le chef de projet expérimenté doit prêter attention tant aux faits qu’à la perception pour naviguer à travers les turbulences du changement organisationnel.

2. les chefs de projet doivent être par nature orientés sur les détails et non pas stratégiques.

Alors qu’il peut être important pour le chef de projet de comprendre comment lire les détails du projet et de bien les suivre, il doit aussi comprendre comment le projet supporte des objectifs organisationnels. Donc, avoir une perspective stratégique ajoute une valeur énorme au jeu de compétences du chef de projet.

3. il faut faire confiance aux experts en toute situation.

Il est vrai que nous devons compter sur les experts mais notre confiance ne doit pas être une foi aveugle. Notre travail de chef de projet dans ce secteur est double. En premier lieu, nous devons extraire les informations et, deuxièmement, nous devons vérifier que les informations sont exactes. Un bon exemple est de demander à un programmeur de fournir une évaluation de l’effort requis pour produire un livrable. Puis de poser certaines questions de vérification car certains membres de l’équipe pourraient oublier d’inclure certaines tâches (documentation, formation utilisateur, transfert opérationnel…), ce qui aboutit en fin de compte à une évaluation défectueuse.

4. les clients savent ce qu’ils veulent.

J’ai connu tant de situations où cette phrase ne pouvait pas être plus éloignée de la vérité. Dans un projet, j’essayais de développer une proposition d’offre de services de conseil pour un client. Nous lui avons demandé de nous fournir une idée de la portée des services nécessaires. Notre proposition a été rejetée parce qu’il était incapable d’aller au-delà de son idée initiale et qu’il avait besoin de voir ce qui fournirait des bénéfices au business.

5. pour réussir, toutes les batailles doivent être livrées et gagnées.

Comme ils/elles sont passionné(e)s, les chefs de projet font parfois la supposition de devoir s’obstiner pour réaliser le travail. Un jour ou l’autre, le compromis est le meilleur chemin de progression. J’ai dû apprendre de la manière la plus difficile qui soit qu’il y a des batailles qui ne valent pas la peine d’être engagées. J’ai dû sacrifier certaines de ces batailles pour pouvoir gagner la guerre.

6. quand il y a une contrainte de temps la meilleure façon de respecter la portée (le contenu) est de sacrifier sur la qualité du produit à livrer.

Voilà une attitude extrêmement dangereuse. Seriez-vous enclins à acheter un vélo qui aurait des câbles de frein effilochés ? Ce qui est souvent confondu avec la qualité est la catégorie. La catégorie est une chose qui peut être sacrifiée en connaissance de cause, pas la qualité. Par exemple, au niveau personnel, si vous avez une contrainte budgétaire, vous pourriez être enclins à acheter une voiture de catégorie inférieure (une Kia plutôt qu’une Mercedes) mais vous n’allez probablement pas achetez celle qui a des freins défectueux.

7. les personnes peuvent porter de multiples casquettes et délivrer avec excellence.

Souvent, tenir des rôles multiples est extrêmement embrouillant. C’est particulièrement vrai si on demande au chef de projet d’être un analyste métier ou un expert technique en plus de ses services de chef de projet. Il finit par remplir avec médiocrité les deux rôles plutôt que l’un ou l’autre avec excellence.

8. l’échec est mauvais en toute circonstance.

Beaucoup d’organisations favorisent la peur de l’échec parce qu’il y a une assomption que, si l’équipe échoue, il y aura d’excessives conséquences négatives pour l’organisation. Une meilleure posture envers ce risque est de dire qu’échouer de manière répétitive à cause des mêmes difficultés est le réel problème. Il est primordial d’utiliser l’échec comme un outil d’amélioration. Si l’équipe a peur d’échouer alors ses membres ne sont pas enclins à agir ni à prendre des décisions.

9. les chefs de projet ne peuvent pas être efficaces dans leur rôle à moins qu’ils n’aient l’expertise technique spécifique au domaine précis du projet.

Vous n’avez pas besoin d’être un ingénieur pour manager un projet de construction ni un programmeur pour un projet de développement logiciel. Tout ce dont vous avez besoin est une compréhension des fondamentaux et de fortes compétences de chef de projet pour diriger le processus. L’expérience de terrain aide mais ne garantit pas le succès. C’est même parfois l’inverse (voir le point #7).

10. une fois le projet démarré, il est difficile de le stopper ou de le terminer.

C’est particulièrement difficile. Et pourtant, si le projet n’atteint pas les objectifs business désirés ou ne produit pas selon le plan, il peut y avoir une bonne raison de l’arrêter en cours de route. Cela n’a aucun sens à continuer à jeter de l’argent par la fenêtre.

Je comprends que la profession s’est améliorée depuis les années 90 et que certains de ces mythes s’estompent. Cependant, nous en voyons toujours quelques restes sous une forme ou une autre.

Si vous avez rencontré d’autres mythes, j’accueillerais volontiers vos remarques.

PMBOK® Guide is a registered mark of Project Management Institute, Inc.

Don’t Get Too Comfortable

https://kerrywills.wordpress.com/2015/01/16/dont-get-too-comfortable-2/  par  Kerrywills

J’ai réalisé beaucoup d’évaluations de santé de projets dans ma carrière. C’est-à-dire que l’on m’a demandé de venir et d’évaluer un projet qui allait mal, identifier les risques/manquements et recommander des solutions pour les atténuer. J’ai aussi été sur beaucoup de projets où des auditeurs ou consultants ont fait de même. L’approche est toujours similaire, elle consiste à demander aux membres de l’équipe quels sont les problèmes puis les organiser par thèmes.

Cette approche d’évaluation de projets n’est ni secrète ni magique et donc nous tous devrions pouvoir prendre un peu de recul sur nos propres projets et nous observer comme le ferait un auditeur externe.

Nous connaissons tous les problèmes sur nos projets, mais ce qui arrive, je pense, est que nous devenons « trop à l’aise » dans nos projets et si familiers de ces problèmes qui « font juste partie des choses ».

Donc mon conseil est celui-ci : ne vous laissez pas aller à vous sentir trop à l’aise.

Sur une base régulière, prenez du  recul et considérez les défis auxquels fait face votre projet et documentez vos recommandations comme si vous étiez cette société extérieure de conseil. Comment résoudriez-vous les problèmes ? Que diriez-vous la direction générale ? Puis examinez comment implémenter ces recommandations.

Par une constante introspection sur votre programme, vous ne tolérerez plus les choses auxquelles vous pourriez vous être habitué.

Alors, commencez au plus vite à vous sentir inconfortable…