Vendre le management de projet reste est un sujet souvent épineux pour les chefs de projet selon les organisations.

Et pourtant… Voici un retour d’expérience original que Cindy Lewis  avait publié en anglais sur AllPM il ya quelques années et intitulé: 

Getting Your Company to Believe in Project Management By Cindy Lewis, PMP, PMI-SP, MCT, MCITP

Imaginez que vous travaillez dans une société qui « ne croit pas » au management de projet. Pourtant, elle fait du management de projet tous les jours sans s’en rendre compte. Que devriez-vous faire pour aider l’entreprise à se convaincre de la valeur de formaliser ce processus ?

En fait, c’est la situation dans laquelle je me trouvais il y a longtemps quand je travaillais dans une société d’ingénierie en architecture qui a réalisait projet sur projet. Nous avions plus de 30 personnes utilisant le titre « chef de projet » même si aucune n’était certifiée PMP® par le Project Management Institute®. A ce moment-là, j’étais fortement impliquée dans mon chapitre PMI local où j’aidais le bureau et travaillais dans l’équipe d’animation côté informatique.

Je n’avais aucune formation professionnelle ni dans l’ingénierie ni dans l’architecture. Donc, essayer de convaincre quelqu’un que PMI et ses principes avaient de la valeur était pratiquement mission impossible et, OUI, certaines personnes ont même ri de moi. Dans cette période de ma carrière, je ne savais pas vraiment dans quoi me spécialiser et si vous jetez un coup d’œil au site de Microsoft, je suis sûre que vous serez étonnés par la quantité de progiciels et certifications que l’on y trouve. Je n’étais vraiment pas certaine de vouloir me spécialiser dans l’administration de serveurs informatiques bien que ce soit déjà 25 % de mon travail. Mon manager du moment (merci Ken si vous me lisez) m’a suggéré de préparer la certification PMP du PMI. Il a pensé que cela aiderait le service informatique à mieux gérer les projets. Quelle super idée!

Donc, je me suis lancée pour obtenir mon PMP et gérer en même temps une autre mise à jour logicielle compliquée. Après 6 mois d’éducation et de formation et le passage de l’examen, j’étais très enthousiaste pour utiliser toutes ces nouvelles connaissances. Je me suis portée volontaire auprès de l’un des chefs de projet de la société pour travailler gratuitement après mes heures de bureau pour voir si je pourrais les aider dans l’exécution de  leurs projets ou au moins sur le planning ou le management des coûts. Et le croiriez-vous ? Non, merci ! fut la réponse. Ceci ne s’est pas produit une seule fois mais tant de fois que j’en ai perdu le compte. Cela m’a vraiment choquée de découvrir que pas une seule personne en dehors du service informatique ne valorisait mes certifications, formations et mon expérience. Donc j’ai décidé de consulter mes collègues du PMI pour collecter leurs suggestions.

Il se trouve que le chapitre PMI local organise un dîner mensuel qui incluait justement une réunion-débat sur un sujet de management de projet d’entreprise (EPM). Les sociétés représentées incluaient Steelcase, Amway et Spectrum Health. La question numéro 1 à laquelle chacun voulait une réponse était « Comment puis-je obtenir l’adhésion au management de projet dans ma société ? ».

Ci-dessous est un bref résumé de ce que j’ai appris :

• Ne pas forcer le management de projet par la voie hiérarchique, du sommet vers le bas

• Démontrer  l’efficacité sur un projet réussi et promouvoir ce succès.

• Essayer un seul « truc » de management de projet à la fois. Par exemple,  le modèle de documentation du contenu/périmètre du projet.

A la base, contraindre au management de projet dans l’entreprise ne marchera pas.

Vous devez vraiment arriver à convaincre. Au fil des années, en travaillant pour une société et en conseillant plusieurs autres, je vois des tas de problèmes à essayer de convaincre les gens de la puissance du management de projet.

Voici une liste de quelques-unes des choses qui ont tendance à attirer les ennuis lors de la mise en œuvre du management de projet d’entreprise :

• 

  Le président impose « nous utiliserons le management de projet »

• L’embauche d’un Directeur du Management de Projet pour surveiller tous les chefs de projets existants dans la société alors que seul ce directeur est certifié en management de projet
• L’organisation de sessions de formation sur des sujets de management de projet pour s’apercevoir que les gens s’y montrent seulement pour le déjeuner gratuit.
• L’achat de logiciel de management de projet en supposant que cela suffira à améliorer le management de vos projets.

Ce qui fonctionne vraiment et que j’ai expérimenté à la société d’ingénierie d’architecture mentionnée ci-dessus était de faire un échange de livre.

Vous pourriez penser que c’est curieux, mais j’ai demandé à un Vice-Président de la société (également architecte) de partager avec moi un livre sur sa profession qui me permettrait d’en apprendre davantage et j’en ai partagé un avec lui dans lequel il pourrait en apprendre plus sur le management de projet. Le livre que j’ai partagé est « Winning in Business with Enterprise Project Management » de Paul Dinsmore. J’ai choisi ce livre parce qu’il est facile à lire et très convaincant sur la puissance du management de projet.

Ce qui a étonné le VP/Architecte et moi-même était des similitudes dans les concepts entre les professions et même plusieurs théories identiques y étaient discutées. Aussi, le VP s’est rendu compte qu’il pourrait vraiment tirer bénéfices d’en apprendre davantage sur le  management de projet. Suite à cette initiative personnelle, je suis involontairement devenue une porte-parole du management de projet dans la société et il a été enclin à essayer certains de mes processus de management de projet et outils sur son projet suivant.

Je réalise que le livre que j’ai choisi pourrait ne pas être le livre le plus récent de la profession, mais voici ce que j’ai aimé de « Winning in Business with Enterprise Project Management » :

• Un principe est inscrit sur une page isolée avant chaque chapitre. Ainsi plus tard vous pouvez les retrouver facilement.
• Les titres de chapitre sont très attractifs … Livres de cuisine, Restaurants et Management de projet d’entreprise et Management de projet, Éléphants et NBA.
• Toute personne ayant une connaissance moyenne du métier pourra prendre le livre et le comprendre.
• Il présente le management de projet d’entreprise d’une manière qui convainc les gens qu’ils doivent le faire.

Depuis ce temps-là, la société a organisé des groupes d’étude pour la certification PMP. Ils organisent des sessions de formation sur le management de projet pour toute personne intéressée et le service financier passe même en revue la valeur acquise (« earned value ») sur les projets de toute la société. Ils ont aussi retiré le titre de « chef de projet » à de nombreuses personnes. Cela a pris à la société une très longue période de temps pour se rendre compte que certaines personnes sont meilleures comme experts et d’autres meilleures au management de projets. Quelle heureuse surprise de voir tous ces changements au fil des ans.

Certains des avantages que cette société a réalisé à mettre en œuvre le management de projet d’entreprise sont :

• de meilleurs processus qui accélèrent les courbes d’apprentissage de projet;
• une meilleure compréhension de la façon de gérer les livrables et de toujours respecter les besoins du client;
• et des projets finalement plus rentables (difficile de faire mieux).

Dans les derniers jobs que j’ai eus, les gens empruntent toujours des livres dans mon bureau.

Quoi que ce soit d’écrit par le docteur Harold Kerzner est toujours parti. J’ai finalement dû commencer à maintenir une liste « de qui a quoi ». Aussi, malgré toutes les nouvelles tendances que vous pouvez lire sur le management de projet, je suggérerais que vous laissiez une chance aux échanges de livres et observiez ce qui arrive dans votre société.

Pour conclure, tout ce que je peux dire est que peu importe ce que vous essayez de faire pour améliorer le succès dans le management de projet, ce qui semble vraiment marcher est « le bruit de couloir » sur le management de projet.

PMP and PMI are registered mark of Project Management Institute, Inc.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

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…