Article N°1 en Juillet 2014 : 20 erreurs courantes faites par les chefs de projet nouveaux ou inexpérimentés Par Harold Kerzner, Ph. D., PMP

 Je vous propose cet article que je trouve très intéressant. Si vous voulez consulter l'original et voir les autres articles proposés http://leblogdumanagementdeprojet.com

J’ai eu la chance de rencontrer le Dr Harold Kerzner, lors d’un séminaire que nous avions organisé avec PMI France Sud et IIL France à Sophia Antipolis. Dr Kerzner est célèbre dans le monde du management projet où ses ouvrages font référence. Comme j’ai pu le constater de visu, il est également très ouvert et toujours enclin à partager sa riche expérience avec les chefs de projet. Il a récemment écrit cet article sur les erreurs à éviter pour les chefs de projet jeunes et/ou inexpérimentés. A mon avis, ces conseils s’appliquent tout autant aux plus âgés d’entre nous, même très expérimentés.

Vous avez lu le Guide PMBOK® plusieurs fois, avez préparé et passé l’examen de certification de chef de projet et vous êtes maintenant un PMP®. Malgré tout, vous continuez à faire des erreurs. Les chefs de projet ne sont pas infaillibles. La plupart des cours de formation en management de projet, mêmes ceux qui se concentrent sur le Guide PMBOK®, mettent en évidence “les meilleures pratiques généralement admises.” Ce que l’on n’apprend pas est ce que ne doit pas faire un chef de projet.

La liste ci-dessous présente vingt des erreurs les plus communes que font les chefs de projet jeunes ou inexpérimentés. Évidemment, il y a plus de vingt erreurs et beaucoup d’entre elles peuvent être spécifiques à certaines industries. Cependant, cette liste est un bon point de départ pour comprendre pourquoi beaucoup de chefs de projet s’attirent des ennuis à cause de leur manière de procéder.

ERREUR #1 : trop de détail

Les chefs de projet inexpérimentés ont tendance à tomber amoureux des structures de découpage du projet. Un chef de projet fraichement nommé m’a demandé de passer en revue son WBS sur un projet informatique. Le projet de trente jours avait 340 lots de travail et certains des lots de travail étaient découpés en minutes plutôt qu’en heures ou en jours.

Alors que le chef de projet était fier de sa réalisation avec la création "d’un WBS micro-détaillé", il a négligé d’envisager le temps et l’effort requis par l’équipe pour manager à ce niveau de détail. Le coût impliqué pour établir probablement 340 comptes d’affectation et les suivre pourrait, en conséquence, facilement augmenter le coût de support en management du projet de cinquante pour cent ou plus.

Les chefs de projet doivent établir un niveau de WBS approprié pour pouvoir le manager. La création de WBS fortement détaillé est une invitation à micro-manager un projet, aliénant ainsi les managers fonctionnels. La plupart des chefs de projet ne possèdent pas aujourd’hui l’expertise technique de créer un WBS détaillé sans aide fonctionnelle. Imaginez-vous participant à la réunion de lancement d’un projet de trente jours et recevant un WBS avec 340 lots de travail.

ERREUR #2 : Prétendre en savoir davantage que ce que vous savez en réalité

Pour la plupart, les chefs de projet possèdent aujourd’hui une compréhension de la technologie plutôt qu’une maîtrise de la technologie, cependant ils persistent à essayer de prendre des décisions techniques sur le projet. Cela entraine souvent les supérieurs hiérarchiques à leur montrer qui est le patron.

La taille et la complexité de projets actuels devraient mettre en évidence pour les chefs de projet qu’ils doivent compter lourdement sur les experts assignés et leaders fonctionnels pour la direction technique et le support. Sur quelques projets, comme dans la R&D, les attributions de chef de projet peuvent être dictées selon un pré-requis de maîtrise technique plutôt qu’une simple compréhension, mais c’est l’exception plutôt que la règle. Les bons chefs de projet connaissent leurs limitations et n’essayent jamais de dicter une solution sans prendre conseil avec les vrais experts.

ERREUR #3 : Préparation d’un planning ambitieux

Au plus le chef de projet est inexpérimenté, au plus optimiste il ou elle sera en préparant la référence de base du planning. Bien qu’il soit agréable d’avoir des calendriers ambitieux, ils sont souvent peu réalistes et peuvent empirer les choses. On ne dit jamais aux clients que le planning est ambitieux et donc ils peuvent penser qu’il est réaliste. Les clients se concentrent alors sur les dates des jalons et maintenant, quand les jalons glissent de l’ambition vers la réalité, vous avez un client malheureux qui se demande quelles seront les prochaines mauvaises surprises.

Un autre facteur à considérer est l’impact sur les évaluations fonctionnelles. Des plannings ambitieux peuvent exiger que des membres de l’équipe exécutent à un niveau plus élevé sur la courbe d’apprentissage changeant ainsi les standards fonctionnels. Les managers fonctionnels peuvent ne pas vouloir changer leurs évaluations et standards. De plus, des plannings ambitieux peuvent exiger que les meilleurs employés fonctionnels de la société soient assignés au projet et cela peut être peu réaliste.

ERREUR #4 : « Surdépendance » sur des Processus Répétables

Les sociétés peuvent passer des années à une méthodologie de management de projet d’entreprise (EPM). L’intention étant que la méthodologie sera utilisée sur tous les projets pour tous les clients et du début à la fin. Même si l’intention a ses mérites, les méthodologies EPM ne prennent pas en compte chaque problème possible qui peut se produire sur chaque projet. Avoir une confiance aveugle dans l’attente que ces processus répétables résoudront vos problèmes est une erreur. Les processus répétables apparaissent sous forme de directives, de formulaires, de modèles et de listes de contrôle. Les processus répétables ne sont pas un substitut ou un remplaçant de l’attention du management, de la prise de décision efficace, ni de la résolution de problèmes. Ce sont simplement des outils à utiliser par le chef de projet et comme nous le savons tous, les projets sont managés par des personnes plutôt que des outils.

ERREUR #5 : Ignorer les Problèmes

Tous les projets ont des problèmes. Les chefs de projet inexpérimentés croient qu’un temps suffisant existe pour résoudre ces problèmes seulement pour découvrir que les coûts afin de corriger ces problèmes plus tard dans le cycle de vie de projet seront significativement plus chers que de faire les réparations en début de projet.

Les chefs de projet ne peuvent pas être sélectifs sur quels problèmes résoudre. Tous les problèmes de projet doivent être attaqués et le plus tôt sera le mieux. Il est vrai que les chefs de projet ne peuvent pas être toujours capables de résoudre les problèmes eux-mêmes. Ils devraient au moins savoir vers quels experts doivent diriger les questions.

ERREUR #6 : Échec à Partager la Responsabilité avec les Managers Fonctionnels

Dans les premiers temps du management de projet, les chefs de projet possédaient une maîtrise technique. Pendant la dotation en personnel d’activités, les chefs de projet négociaient des ressources spécifiques qui étaient alors placées sous la direction technique du chef de projet plutôt que du manager fonctionnel. Le manager fonctionnel conservait seulement le contrôle administratif des ressources. Aujourd’hui, les chefs de projet ont juste une compréhension de la technique et sont donc en discussions avec les managers fonctionnels sur les livrables plutôt que sur les personnes.

En négociant sur les livrables, les ressources fonctionnelles restent toujours dans la supervision et le contrôle directs du manager fonctionnel. Dans ce scénario, les managers fonctionnels doivent être enclins à partager la responsabilité du succès avec le chef de projet.

Des chefs de projet inexpérimentés croient qu’ils portent seuls la responsabilité du succès du projet. C’est une erreur pour le chef de projet de ne pas partager cette responsabilité avec les managers fonctionnels. Parfois, le support exécutif est nécessaire pour mettre en application cette responsabilité partagée parce que cela pourrait ne pas faire partie de la culture d’entreprise.

ERREUR #7 : Placage à l’or fin des Livrables

La plupart des chefs de projet veulent satisfaire le client. Cependant, il y a des limites que le chef de projet ne devrait pas dépasser. Le « placage à l’or fin » des livrables après que le contenu ait été accepté peut s’avérer très coûteux. De plus, le client pourrait être tenté de croire qu’il peut obtenir ces "suppléments plaqués or" gratuitement sur de futurs projets car la nouvelle norme est établie.

ERREUR #8 : Échec à Comprendre Ce que Parties prenantes et Sponsors Veulent Entendre

Un des pré-requis pour passer le l’examen PMP®  est une compréhension du management des Coûts et plus spécifiquement, les formules attribuées à la mesure de valeur acquise. Bien qu’il y ait évidemment du mérite à cela, la mesure de la valeur acquise est seulement une partie de ce que les parties prenantes et des sponsors veulent entendre. Il est impératif que, dans le management des parties prenantes, les chefs de projet interviewent celles-ci pour savoir quelles informations elles considèrent comme importantes.

Chaque partie prenante peut vouloir un jeu différent de mesures de suivi ou d’indicateurs de performance (KPI). Le chef de projet peut alors trouver nécessaire de développer un tableau de bord de performance différent pour chaque partie prenante. Cela pourrait générer des surcroîts de coût significatifs si non planifiés dans le budget.

ERREUR #9 : non compréhension pleine et entière des besoins

Plus le chef de projet est inexpérimenté, plus grande est la probabilité qu’il/elle utilisera son interprétation des besoins plutôt que de consulter les experts du sujet. Cela peut mener à une erreur de sélection dans l’approche technique et des changements onéreux lors des étapes ultérieures du projet.

Il y a des problèmes sous-jacents qui peuvent générer ce problème, le plus répandu étant le moment choisi pour embarquer le chef de projet. La 4ème édition du PMBOK® parle de la compréhension des besoins des parties prenantes. Souvent, le chef de projet n’ pas une interface directe avec parties prenantes au départ. Ce sont plutôt les ventes et le marketing qui préparent une réponse à appel d’offres. Le chef de projet hérite alors des besoins et peut ne pas être entièrement conscient des suppositions faites lors de la préparation de la proposition.

ERREUR #10 : Refus de Demander de l’Aide

Une des erreurs les plus communes faites par les chefs de projet inexpérimentés est de croire que demander de l’aide les fera paraître incompétents aux yeux de leurs pairs et du management. Rien ne pourrait être plus éloigné de la vérité. Les bons chefs de projet connaissent leurs limitations et recherchent toujours de l’aide le plus tôt possible.

Le refus de rechercher l’aide peut aboutir aux dérapages de planning et dépassements de coûts. Si le chef de projet attend trop longtemps avant de rechercher de l’assistance, le nombre d’options pour corriger le problème peut diminuer. Les sponsors devraient encourager des chefs de projet à demander de l’aide le plus tôt possible, mais il ne faut pas s’attendre à ce que le sponsor soit le dépotoir pour tous les problèmes que le chef de projet ne peut pas résoudre.

ERREUR #11 : Ignorer un Problème

Ignorer des problèmes est semblable à l’erreur précédente du non désir de demander de l’aide. Cependant, ignorer un problème pourrait aussi signifier que le chef de projet pourrait résoudre le problème, mais refuse d’attaquer le problème dès qu’il se présente.

Les problèmes ne s’en vont pas. Au lieu de cela, ils grossissent en taille, les occasions de résolution opportune diminuent et les risques peuvent augmenter significativement. Savoir qu’il y a un problème et ne pas l’adresser peut être considérer comme “un baiser de la mort” par le sponsor au point que le projet peut être arrêté.

ERREUR #12 : Croire aux Sauveurs et aux Miracles

Peut-être la raison la plus commune d’échouer à demander l’aide ou ignorer un problème consiste en ce que le chef de projet cherche un sauveur ou un miracle pour résoudre le problème. Tandis que les miracles peuvent arriver, comme une percée technique rapide, les chances que cela se produise sont très très faibles.

Les chefs de projet doivent se développer au début du projet, une stratégie pour traiter les problèmes. L’espoir n’est pas une stratégie. C’est plutôt une mauvaise raison d’éviter d’adresser un problème.

ERREUR #13 : Promettre des Récompenses

Les chefs de projet inexpérimentés font souvent des promesses de récompense sachant parfaitement qu’ils n’ont pratiquement aucune responsabilité dans les salaires et compensations. Cependant, ils croient que c’est une façon efficace de motiver l’équipe. Les chefs de projet ne sont pas en mesure de faire des promesses de promotion, heures supplémentaires (rémunérées), bonus, missions de travail futures et autres sujets similaires, mais persistent à le faire.

Les membres expérimentés de l’équipe savent ce que les chefs de projet peuvent ou pas promettre et accomplir. Le résultat est une équipe démoralisée qui a peu de foi dans le chef de projet et ne lui font pas confiance. Les membres de l’équipe peuvent aussi éviter de travailler pour ce chef de projet à l’avenir.

ERREUR #14 : Échec à Voir les Dépendances entre Projets

Les chefs de projet inexpérimentés sont souvent si amoureux de leur projet qu’ils n’arrivent pas à voir autre chose autour d’eux. Le résultat est qu’ils finissent par prendre des décisions seulement pour ce qui est dans le meilleur intérêt de leur projet tandis que cette même décision peut ne pas être dans le meilleur intérêt de la société dans son ensemble.

Les chefs de projet doivent être enclins à prendre des décisions business/société plutôt que des décisions uniquement de projet et cela exige une bonne compréhension des dépendances entre les projets et l’activité en cours. Se battre pour avoir les meilleures ressources de la société peut ne pas être une bonne décision pour la société si votre projet a une priorité très faible en rapport d’autres projets.

ERREUR #15 : Ne pas dire pas au Client qu’ils ont tort

Croire que le client a toujours raison n’est pas nécessairement correct dans le management de projet. Bien que les chefs de projet veuillent satisfaire les clients, ils doivent être enclins à dire, “votre décision ou idée est incorrecte.” C’est particulièrement vrai quand les clients font des demandes de changement ou changer la direction du projet sans entièrement en comprendre les ramifications. Quelques personnes pensent que le mot le plus important dans le vocabulaire du chef de projet est "Non".

ERREUR #16 : Montrer à tous qui est le Patron

Certains chefs de projet se voient comme "présidents" du projet. Même si ce n’est pas nécessairement mauvais, les chefs de projet peuvent devoir se rendre compte que c’est seulement dans le titre et que celui-ci peut venir avec une très faible autorité réelle. Le management de projet est souvent décrit comme un leadership sans autorité.

Les chefs de projet qui essayent de montrer qu’ils « sont en charge » peuvent s’aliéner des membres de l’équipe, particulièrement les membres de l’équipe qui comprennent vraiment le management de projet. Parfois, les membres de l’équipe laisseront le chef de projet croire qu’il/elle est responsable et utiliseront ensuite le PM comme endroit où déposer toute décision sachant que le PM pourrait prendre la mauvaise décision.

ERREUR #17 : Échec de Parvenir à connaître Votre Équipe

Les personnes qui travaillent dans des équipes de projet, particulièrement dans une structure matricielle, savent qu’ils ont une maison dans leur secteur fonctionnel à la fin du projet. Les chefs de projet le savent aussi et pourraient donc faire l’erreur de penser que d’apprendre à connaître l’équipe est inutile  puisqu’ils pourraient ne plus jamais interagir avec les équipes après que le projet soit achevé.

Le management de projet est un effort d’équipe. Si le PM échoue à parvenir à connaître l’équipe, les membres de l’équipe ne peuvent pas se sentir comme faisant partie de l’équipe. Connaître l’équipe peut favoriser de meilleures communications, la coopération, la collaboration et la confiance. Et si vous ne croyez pas que, c’est important, essayez de manager “un projet en difficulté” et voyez ce qui arrive si vous ne connaissez pas votre équipe.

ERREUR #18 : Échec à Isoler l’Équipe de la Politique

On ne devrait pas permettre à des facteurs exogène d’entreprise, particulièrement la politique, d’avoir un impact sur la performance journalière de l’équipe. Le chef de projet et le sponsor de projet doivent isoler l’équipe de la politique et autres facteurs similaires.

La politique peut amener des membres de l’équipe à perdre leur sens de la direction du le projet et la performance peut en souffrir. Aussi, les membres de l’équipe qui ne sont pas politiquement avertis peuvent être entrainés dans des secteurs dont ils ont une connaissance limitée et empirer les choses.

ERREUR #19 : Ne pas Dire "Non"

Le mot "Non" pourrait très bien être le mot le plus important dans le vocabulaire du chef de projet. Cela s’applique aux transactions tant avec le client qu’avec l’équipe. Après le feu vert au projet, les clients essayent souvent de faire accepter des modifications sans coûts additionnels avec l’excuse de garder le client satisfait. Cela peut mener à des conséquences désastreuses.

Une autre raison de dire non est quand les membres de l’équipe se plaignent qu’ils soient surmenés et essayent de faire faire leur travail au PM. Même s’il est vrai que les chefs de projet sont autant managers qu’hommes d’action, les chefs de projet doivent connaître leurs propres limitations.

ERREUR #20 : Ne pas Choisir les bonnes batailles

Pour être bon à la guerre, il faut savoir quand attaquer, quand défendre et quand reculer, afin de se battre de nouveau. Les chefs de projet inexpérimentés ont tendance à manquer de discernement sur quand se battre et quand renoncer. Au lieu de cela, ils entrent souvent dans les batailles qui ne sont pas les leurs ou ne devrait pas entrer du tout. Les chefs de projet doivent savoir quel champ de bataille est le bon pour eux.

Évidemment, cette liste n’est pas exhaustive. Néanmoins, elle fournit quelques conseils sur le type de problèmes que les chefs de projet doivent comprendre. Ces erreurs peuvent être corrigées et peuvent économiser un temps et argent significatifs.