Management de Project International Du Discours de La Méthode a La Pratique Exemples Concrets - Riana Andrieux [French]

SECTION I Parlons plutôt du Management de Projet « Quelqu’un qui maîtrisera les méthodes fondamentales de sa discipline et aura appris à penser et à travailler de manière autonome saura

toujours faire son chemin, sans compter qu’il sera mieux en mesure de contribuer aux progrès et aux bouleversements que celui dont la formation se sera essentiellement résumée à acquérir des connaissances de détails. » Albert Einstein

Les raisons d’être de cet ouvrage Le management de projet de papa où l’on pilote les projets à vue, au petit bonheur la chance, a montré ses limites d’autant plus que, contrairement au passé, les projets actuels ne connaissent plus de frontières et font intervenir des ressources, des parties prenantes des

quatre coins du monde. L’un des facteurs d’échec d’un projet est le manque d’éducation ou de culture en management de projet de l’organisation, ou encore l’inadéquation dans les compétences administratives, humaines et techniques du Manager de Projet, ainsi que son inexpérience. Un autre facteur est le manque de méthodologie ou la mauvaise application d’une méthodologie au sein des organisations. Les projets échouent ou vont dans le mur, moins souvent à cause du mauvais choix de technologie que de mauvaises pratiques ou du manque de culture de management de projet, de l’organisation en général et du Manager de Projet en particulier.

Figure 1: Le management de projet s'industrialise

L’expertise en management de projet est aujourd’hui une compétence stratégique pour les entreprises. En effet, le métier de Manager de Projet n’est plus considéré comme le métier par « accident ». Il fut une époque où les tâches, actuellement du ressort du Manager de Projet, étaient morcelées et indistinctement exercées par divers collaborateurs. Aujourd’hui, on ne devient plus Manager de Projet par accident, par la volonté de son boss ou parce que c’était le seul endroit où atterrir après parachutage. En somme, on ne devient plus manager par manque de choix. On devient professionnel du management de projet par formation et par choix de carrière. Ne s’improvise

pas non plus Manager de Projet qui veut, cela nécessite une formation et surtout des compétences. En concordance avec la réalité professionnelle, le management de projet est devenu une discipline à part entière dans les écoles et universités. D’ailleurs, le nombre de centres de formation et de certifications professionnalisant le métier ne cesse de s’étendre. Selon PMI, la demande de professionnels du projet est énorme. Leur prévision est qu’il y aura en moyenne un million et demi de nouveaux emplois vacants dans le secteur pour chaque année de la prochaine décennie. Cette demande dépasse de loin l'offre et a précipité une crise mondiale de l'éducation en management qui, si elle

n'est pas rectifiée, pourrait mettre en danger $4.5 trillions du PNB d'ici à 2016.

Exemple 1: Organisation fonctionnelle par projet et équipes éparpillées dans le monde

Cette forte et rapide croissance est

du à une prise de conscience des entreprises qui réalisent maintenant que les projets représentent les leviers de la productivité et le passage à une organisation transversale par projets s'est accompagné de l'émergence du métier de Manager de Projet, particulièrement recherché aujourd’hui par les entreprises. Désormais, cette fonction spécialisée et hautement critique est devenue incontournable pour le succès d’une organisation. Les prédictions catastrophistes de pénurie internationale de professionnel du management soulignent donc vraiment la généralisation de fonctionnement en mode projet des entreprises. Avec une demande qui, nous l’avons vu, est loin

de se tarir, le métier dispose d’un bel avenir. Les managers de projet talentueux seront dès lors très demandés et les compétences en management de projet se rendront indispensables pour l’industrie entière.

Evolution du management de projet On peut donc constater un « shift » du modèle traditionnel vers un nouveau modèle où des professionnels du management de projet s’attellent au management de projet. Dans le futur, certaines entreprises, qui n’ont pas encore ce degré de maturité en termes de culture de management de projet, vont très vite réaliser qu’il n’y a pas d’autres choix dans un monde aussi compétitif que, d’une part, former leurs employés au standard de management international et d’autre part, inculquer cette culture à

l’ensemble de l’organisation. Pour qu’une méthodologie de management de projet fonctionne, il faut qu'elle soit ancrée dans les gènes d'une organisation et pas seulement dans ceux des managers de projets. Il faut également qu'elle soit simple et inclusive - cela ne doit pas être du latin ni du grec ni du chinoispour les employés et surtout pour les cadres dirigeants. Cet ouvrage a pour objectif de mettre en lumière, grâce à des cas pratiques rencontrés en entreprise, la science et l’art de manager un projet en utilisant les méthodologies standard internationales. Il comprend un concentré de cas concrets et d’exemples

pratiques que l’on ne rencontre pas en une semaine de formation, mais bien sur le terrain. Ainsi, l’ouvrage entend démontrer, comment appliquer de façon pratique les techniques, les outils et les processus au management de projet. Le métier de Manager de Projet, considéré par certains comme une activité très administrative voire liée au secrétariat, est devenu une science, avec ses processus, et un art de la façon d’interagir avec les gens. Il ne faut jamais oublier qu’un Manager de Projet obtient des résultats par l’intermédiaire d’autres personnes et de son équipe. Autrefois, on appelait le manager

« chef » de projet, et son autorité était directement assimilée à sa force hiérarchique et bureaucratique. Aujourd'hui, dans la matrice d’organisation composite où l’équipe est composée de différentes entités, l'autorité du « chef » est assimilée à sa capacité à négocier et à déléguer auprès des acteurs. Il fait davantage de management aujourd’hui.

Le composant culturel Le Manager de Projet a une responsabilité sur le budget, les délais et la performance et cela ne s’improvise pas. Il doit également être capable de constituer une équipe, de résoudre les conflits, négocier avec les fournisseurs, manager la relation client, préparer des

décisions stratégiques pour les présenter à sa hiérarchie et cela non plus ne s’improvise pas. Le Manager de Projet doit tenir compte de la différence de culture entre les parties prenantes. En effet, on ne manage pas de la même façon un Japonais avec son nemawashi ou pre-arrangement, requérant que les problèmes soient résolus en privé, un Chinois avec son Guanxi ou maintenance du réseau de relation, qui favorise l'échange mutuel entre deux protagonistes où les deux parties doivent retourner la faveur faite à l'une ou à l'autre, un Russe avec le Blat ou rapports d'affaires, consistant en l’échange de faveurs, ou encore un Oriental avec son wasta ou piston, c’est-à-dire le recours

aux relations, les trafics d’influence et le favoritisme. Chaque personne sur un projet vient et compose avec sa culture. Démétrius le Cynique disait des gens sans culture : « qu’ils parlent ou ils pètent, c’est la même chose ». Il en va de même sur un projet national ou international. De même, manager les stakeholders ne s’improvise pas non plus, surtout si leurs parties prenantes sont de différentes nationalités. Le Manager de Projet est donc devenu la force principale pour livrer des résultats dans la production d’une organisation. Le projet est devenu le levier de la productivité et le Manager de Projet s’est rendu indispensable au business. En somme, l’expertise en management

de projet est une compétence stratégique pour les entreprises. Cet ouvrage, dans un style fondamentalement oral, comme lors d’un cours de management de projet, souhaite illustrer à l’usage des lecteurs la façon de laquelle on manage les projets internationaux de nos jours, en se basant sur une méthodologie standard internationale de manière à éliminer les facteurs d’improvisation. Cet ouvrage est pareil à une recette, comme il en existe d’autres, s’inspirant des méthodologies en vogue sur le marché, pratiquées au niveau mondial par plusieurs entreprises internationales. Cette recette montre comment on

mélange les différents ingrédients (divers processus, un carcan de techniques, une pléthore d’outils, des domaines de connaissance à maîtriser, des soft skills à posséder, etc.) pour cuisiner tout type de plat de projet pour tout type de secteur. Faire les choses de façon ad hoc, comme le faisait papa, peut coûter une fortune. On tâtonne, on expérimente, on tente une chose puis une autre. Je reconnais qu’on ne va pas tous manager des projets à 53 milliards de dollars pour la reconstruction d’un pays, où les conflits politiques, les risques de sureté et de sécurité sont autant d’obstacles à surmonter, surtout combinés aux fraudes financières et où le seul retour sur

investissement du projet est la démocratie restaurée. Je vous l’accorde. Mais même un simple projet a besoin de suivre une méthodologie. Vous allez vous en rendre compte très vite : même sur un projet à petit budget, plus vous aurez de parties prenantes, plus il deviendra impossible de faire du management de projet au flair, au feeling, aussi grand ou expérimenté que soit le manager du projet. Une méthodologie doit donc s’imposer. La méthodologie n’est pas non plus une baguette magique, mais elle augmente la chance de réussite du projet. Si l’expérience glanée ici et là, en trébuchant auparavant sur des projets, aide toujours pour manager le projet

suivant, une méthodologie offre un cadre que l’on peut appliquer d’un projet à l’autre.

Vocabulaire du management de projet L’homme du XXIe siècle est multiculturel et le Manager de Projet doit l’être également. Il doit pouvoir intégrer et utiliser les méthodologies de standard internationales ainsi que leurs vocabulaires communs, qui sont des éléments essentiels de n’importe quelle discipline professionnelle, dès lors qu’un projet dépasse le cadre national. En effet, l’absence d'une langue commune ou l’existence de niveaux différents dans la maîtrise de la langue

au sein de l’équipe peuvent transformer un propos mal formulé, dans une conférence téléphonique ou un courrier électronique, en conflit larvé. Ainsi, l’un des objectifs de cet ouvrage est de familiariser le lecteur avec les vocabulaires internationaux au travers de définitions, d’exemples, de techniques et outils présentés dans cet ouvrage. Pour cette raison, et afin que le lecteur se familiarise très vite avec la terminologie en vigueur, la version originale des terminologies sera gardée avec un sous-titre en français. Ainsi, on énoncera Earned Value (EV) à la place de Valeur Acquise, Work Breakdown Structure (WBS) à la place de Décomposition Hiérarchique des

Travaux, mais cependant, le sous-titre ne sera jamais bien loin. En téléconférence avec vos collègues étrangers, vous saurez donc exactement de quoi il retourne avec ce vocabulaire commun, rien ne sera perdu dans la traduction. Je me souviendrai toujours de cette personne qui, lors d’une conférence téléphonique en anglais avec des équipes connectées de partout dans le monde, où la conversation portait sur un projet à Beijing, à la fin de la conf call, fit observer que le sujet ressemblait ‘vachement’ à un projet qu’il était en train de préparer pour Pékin.

De la méthodologie à la pratique

Nietzsche disait que la puissance, c’est la méthode. A l’image des professions juridiques, comptables ou médicales, la profession de Management de Projet dispose aussi de son guide de bonnes pratiques. Il en existe plusieurs sur le marché tels que PMI, Prince 2, Six Sigma et CMMI entre autres. Prince 2 fut en Grande-Bretagne, dans les années 70, par l’OGC (Office of Government Commerce). Le CMMI est né aux ÉtatsUnis, dans les années 80, au département de la défense. Quant au Six Sigma de Motorola, il doit sa renommée, dans les années 90 à la décision de General Electric de Jack Welsh de l’appliquer et de l’améliorer.

Ce livre a aussi pour humble ambition de montrer comment mettre en pratique la méthodologie proposée par le Project Management Institute (PMI®) en traitant d’exemples concrets. Il ne s’agit pas ici d’un fervent se référant à des idéaux supérieurs concernant cette méthodologie choisie. Mais l’auteur, votre humble serviteur, est certifié Professionnel du Management de Projets (PMP®) de cet institut et donc, bien que formé aux autres méthodologies du marché, compte s’inspirer ici de ce qu’il a pratiqué dans plusieurs entreprises, essentiellement de PMI®. Aussi, l’ouvrage ne s’attardera pas sur le blabla théorique mais se focalisera plutôt sur la pratique. S’il est bon de

connaître la théorie, il est encore mieux d’être capable de l’appliquer dans la pratique. Hélas, il n’existe que peu d’ouvrages apportant une vision empirique sur ce sujet, illustrant au travers de cas concrets, d’application des outils, techniques et processus décrits par la théorie. C’est ce qui m’a poussé à rédiger cet ouvrage. Une approche holistique a été adoptée lors de la rédaction de ce livre, afin de ne laisser aucune zone d’ombre pour le lecteur désireux de monter une culture de projet dans son organisation et sur le management de projet international. Holistique paraît un bien grand mot appliqué à ce sujet. J’ai moi-même dû vérifier sa signification dans le

dictionnaire et bien qu’ayant cherché à utiliser un autre qualificatif, à chaque fois, je retombais sur ce mot. Faute d’une expression plus simple, on comprendra ici holistique comme l’approche globale du management de projet. On ne peut pas manager un projet sans savoir ce qu’est réellement un projet. Et inversement, on sait ce qu’est un projet mais connaît-on toutes les étapes à parcourir pour manager le projet avec succès ? J’ai vu des managers de projet qui ne savaient pas par où commencer. Cela semble évident mais l’on commence toujours par la phase d’initiation.

Au fil des pages, on montrera en détails comment on peut utiliser de façon efficace les processus, techniques et outils définis dans le guide du Corpus des Connaissances en Management de Projet (PMBOK®). Il passe de la théorie à la pratique car, bien que ces guides existent, ils demeurent trop théoriques et ne traitent pas de leur application aux projets. Ce guide est un produit du Project Management Institute (PMI). Cet institut, fondé en 1969, association professionnelle à but non lucratif qui propose les méthodes de Management de projet illustrées dans cet ouvrage, a vu le jour aux États-Unis, son

siège se trouvant à Philadelphie en Pennsylvanie. Ses standards de Management de Projets sont aujourd’hui répandus dans à peu près 200 pays dans le monde. Dès lors, si l’on veut bénéficier d’une expérience internationale, autant maîtriser les méthodologies en vogue à l’échelle internationale. Les organisations pensent tout connaître du sujet jusqu’à ce qu’elles démarrent un projet. Elles se convainquent qu’elles disposent de petits projets ne nécessitant pas de vrai cadre de management de projet et cette absence, selon elles, leur fait économiser de l’argent. Ces gens qui pensent petit et pas cher finissent toujours par payer plus cher leur

amateurisme. Je suis tenté de citer ici quelques compagnies, mais ce ne serait pas correct et pourrait ruiner ma carrière. Je m’en abstiendrai donc. L’ouvrage se présente également comme une fenêtre avec vue sur la vie dans les tranchées du management de projet : les épreuves, les erreurs, la fougue des novices, les déceptions, la défaite, les petites comme les grandes victoires, toutes ces étapes par lesquelles passe le Manager de Projet. C’est un ouvrage d’appropriation conçu pour que le lecteur puisse se familiariser avec les grandes notions de la méthodologie de management de projet et apprivoiser le concept illustré par les

différents exemples de cas concrets réellement vécus par l’auteur ou ses collègues. L’ouvrage est nourri de l’expérience de collègues managers de projets, de leurs laboratoires de vie également.

À qui cet ouvrage s’adresse-til ? « Les analphabètes du XXIe siècle ne seront pas ceux qui ne savent pas lire et écrire, mais ceux qui ne savent pas apprendre, désapprendre et réapprendre. » Alvin Toffler

Ce livre capture l’essence de la profession du management de projet. Il offre une base, un socle sur lesquel s’appuyer pour le découvrir. Destiné aux étudiants ou aux exécutifs (CEO, CFO, CTO, VP, etc.) qui n’ont qu’une vague ou aucune notion de management de projet, pour mener à bien leur projet et s’évaluer - pour ceux qui pratiquent déjà le management de projet - pour implémenter une culture de management de projet dans une entreprise, ou encore préparer leur diplôme de professionnels en management de projet. J’insiste sur le rôle de l’organisation dans la culture du management de projet. Il est destiné à ceux qui pensent que se marrer et faire la fête n’est pas une fin en soi et qu’il est

primordial de poursuivre l’instruction tout au long de sa vie, quelque soit le niveau où l’on se trouve dans sa carrière et même si l’on maîtrise déjà tout. Cet ouvrage a été conçu à l’attention de ceux qui souhaitent appréhender la théorie du management de projet au moyen de la pratique. Je voulais produire de l’or, pour ceux qui ont soif d’augmenter leurs connaissances, pour démontrer l’importance d’une culture du management de projet au sein d’une organisation et pour ceux avides de les intégrer et de les appliquer dans leur milieu professionnel. Je veux m’adresser aux étudiants ou aux professionnels juniors désireux d’apprendre, ainsi qu’aux professionnels

confirmés prêts à désapprendre et à réapprendre. A cette fin, vous trouverez des exemples concrets tirés de faits divers réels - où les noms ont été changés pour éviter toute poursuite judiciaire -, des outils et techniques accompagnés de templates dont on peut immédiatement se servir dans sa vie quotidienne, où le copier-coller est autorisé.

Pourquoi le CEO (Chief Executive Officer) ou PrésidentDirecteur Général (PDG), les vice-présidents (VP) et autres directeurs d’une organisation devraient-ils lire cet ouvrage ? « Actualiser vos connaissances, lisez. » Richard Templar On doit avoir une approche TopDown, venant du conseil d’administration, pour inculquer efficacement une culture de management de projet au sein d’une organisation. Et,

pour cela, ces PDG, VP, etc. doivent vraiment savoir ce que comportent les méthodologies de management de projet. Ces personnes doivent faire un choix sur la méthodologie à inculquer à leurs employés pour que leur organisation demeure compétitive. Ils connaissent le ratio entre projets réussis et manqués dans leur organisation, mais ne savent peut-être pas comment y remédier, mis à part employer des consultants externes et croiser les doigts pour qu’ils leur apportent la solution. Cet ouvrage illustre l’avantage, pour une entreprise, de bénéficier d’une méthodologie. La méthodologie utilisée par une organisation est toujours à l’image de ceux qui composent le comité de

direction. J’ai vu des entreprises qui pensaient posséder une réelle méthodologie de projet en s’adjoignant une secrétaire, un leader technique ou une personne ayant suivi une formation de Manager de Projet en 3 jours pour expédier le projet. Et la culture de management de projet s’arrête là. Il y a du chemin. Cet ouvrage est un aperçu d’une approche de management de projet basée sur une méthodologie. Cela peut leur donner une idée réelle de ce qu’il se passe dans les tranchées du management de projet, et donc une idée de ce qu’il faut implémenter comme méthodologie pour les types de projets au sein de leur organisation. Je peux

toujours offrir mes services pour les épauler à ce sujet. En outre, la plupart des projets réussis ont toujours eu le support et l’attention des exécutifs, sans cela, il est difficile pour un projet de réussir pour une raison très simple : même ces personnes haut placées n’ont que faire du projet. Quand on déclare à tout-venant que le CEO, VP ou n’importe quel exécutif a signé le contrat ou la charte du projet, les gens ont tendance à s’investir plus.

Pourquoi les professionnels désireux de devenir managers de projet devraient-ils lire cet ouvrage ?

« Ce qui importe avant tout est de ne pas cesser de s’interroger. La curiosité a sa raison d'être. On ne peut s’empêcher d’éprouver un sentiment d' effroi mêlé d'admiration lorsqu'on réfléchit aux mystères de l' éternité, de la vie et de la merveilleuse structure de la réalité. Il suffit d’essayer d'en comprendre un peu plus tous les jours. Il ne faut jamais perdre une sainte curiosité. » Albert Einstein C’est une évidence. Vous avez le bon ouvrage entre vos mains, vous y trouverez la méthodologie, les outils, les techniques avec pléthores d’exemples sur comment les utiliser. Je développe

dans cet ouvrage les compétences, principalement les soft skills, à acquérir impérativement pour devenir un bon Manager de Projet. Je vous livre également ma version des faits sur comment manager un projet, par où commencer, reconnaître les étapes obligatoires, comment faire des estimations de coûts, comment être un bon leader d’équipe et comment s’amuser aussi de temps en temps. Comment réagir en temps de défaite et de victoire (quick win), car le parcours de management de projet en est jalonné. J’espère qu’avec cet ouvrage je vous aurai incité un peu plus à devenir Manager de Projet. Je vais me montrer totalement subjectif mais, à mon sens,

Manager de Projet est le meilleur job de la planète car il embrasse tout : la finance et la comptabilité, le business et le supply chain, la technique et la technologie, les ressources humaines et j’en passe.

Pourquoi les étudiants devraient-ils lire cet ouvrage ? « Les connaissances nouvelles que nous aurons acquises demain doivent évidemment modifier le point de vue que nous avons aujourd’hui. » Trine Le métier de Manager de Projet est en forte demande et l’on a besoin de personnel à la formation appropriée. Les termes « projet » et « management de

projet » sèment souvent la confusion, paraissent nébuleux, surtout quand on n’a pas encore baigné dans le grand bain du monde des entreprises. Cet ouvrage peut se révéler très profitable aux étudiants désireux de s’orienter vers le management de projet. Parce qu’en plus de traiter d’une méthodologie de management de projet, il offre des cas concrets et pratiques pour démontrer ce qu’est réellement le management de projet et ce qu’il implique. Les exemples livrent un aperçu du monde des entreprises et de ce que l’on attend du métier de Manager de Projet. L’ouvrage amène le lecteur dans les tranchées du management de projet, dans un cadre qui n’est pas académique

mais issu du vrai monde professionnel.

Pourquoi les formateurs en management de projet devraient-ils lire cet ouvrage ? Car entre formateurs, on demeure curieux de voir comment l’autre aborde ses cours. Cet ouvrage offre mon approche de la formation et enseignement du management de projet. Je n’y enlèverais rien. Je ne dis pas qu’il est complet non plus ou ne contient pas d’erreur, cela peut arriver, et d’ailleurs je remercie à l’avance vos retours sur les éventuelles remarques à suggérer pour cet ouvrage.

Pourquoi les managers de projet, préparant leurs certifications PMP® devraientils lire cet ouvrage ? Simplement parce que l’ouvrage contient beaucoup d’exercices qui se retrouvent souvent dans les examens de 4 heures pour obtenir ladite certification. Il livre également des exemples qui illustrent les définitions données par le PMBoK® que l’on doit connaître par cœur.

Pourquoi une certification en PMP® est-elle utile ? Quand vous dites posséder la

certification PMP® (Professionnel du Management de Projet), solide et unanimement reconnue dans le monde, cela implique que vous disposez d’une certaine expérience du management du projet et que vous êtes familiarisé au moins à la méthodologie défendue par PMI® (Project Management Institute) dans la 4e édition du PMBoK® (Project Management Book of Knowledge). Il faut savoir que le professionnel qui valide ses compétences par la certification PMP® est sans conteste considéré par ses collègues et surtout par les recruteurs, comme un véritable professionnel du métier. C’est une reconnaissance de votre expertise en management de projet, c’est votre

sésame pour débuter votre carrière internationale. Ce phénomène de légitimation se trouve renforcé par le mouvement continu de standardisation, de quasi industrialisation des méthodologies de management de projet par les entreprises. Celles-ci apprécient considérablement la certification PMP®. Elles recrutent en effet de plus en plus de personnel certifié PMP® et forment leurs employés à la méthodologie PMBOK® pour pourvoir aux carences en Manager de Projets professionnels. Cette certification est même devenue une exigence courante aux États-Unis, que ce soit en phase de recrutement ou en appel

d'offres. Aujourd'hui, elle prend pied en Europe. Le PMP ajoute une autre dimension, lève un doute lors de l’entretien, vous reconnaît déjà comme expert en management de projet. Il n’y a rien de pire que de se sentir sans dimension, sans substance, vide. Au vu des motifs exposés ci-dessus, le professionnel détenteur de la certification s’ouvre à d’incalculables opportunités de carrière.

Pourquoi les managers de projets confirmés, détenteurs de leur certification PMP® ou de celle d’une autre organisation, voudraient-ils lire cet ouvrage ?

« C'est grâce à l’esprit de curiosité que nous progressons et découvrons le monde. » V.-R. Dhiravamsa Parce que plus on en sait, plus on désire en savoir, plus l’on se montre curieux de ce que font les autres. Souvent, ceux qui ont de l’expérience et qui sont déjà confirmés ou certifiés restent immobiles et croient tout savoir. Cet ouvrage montre une perspective du management de projet, un angle peut-être différent du leur. Obtenir la certification PMP® ou autre en management de projet est comme posséder le permis de conduire : on peut l’avoir obtenu depuis des années, mais si l’on a très peu roulé, on

ne peut s’estimer expérimenté. Ajoutons aussi qu’au moyen de cet ouvrage, les managers de projet déjà certifiés ont l’opportunité de rafraîchir leurs acquis et de tirer parti du cas présenté pour méditer sur leur approche personnelle. Auraient-ils abordé le projet de la même manière ? Toute connaissance que l’on ne continue pas à développer régresse.

Pourquoi ceux qui souhaitent développer leurs carrières dans le management de projet devraient-ils lire cet ouvrage ? « L’homme privé d’éducation ne sait

pas se servir de sa liberté. » Kant J’en ai connu des personnes qui, une fois leur diplôme reçu, se sont considérées comme des « élites » et ne se sont, depuis, plus jamais remises en question. Eh bien, cet ouvrage ne tombera jamais dans leurs mains, car ces gens savent déjà tout. Cet ouvrage s’adresse à ceux qui veulent développer une compétence dans leur métier lié au management de projet. Ce qui compte n’est pas le niveau que l’on désire atteindre : être le meilleur dans son domaine, être le meilleur au monde ou encore être maître de l’univers ; ce qui compte, c’est de faire de son mieux et de

donner le meilleur de soi-même à tout moment. Et, avec un peu de chance, on atteint le niveau où l’on veut être. Et on se sent même parfois invincible quand on adopte cette attitude. La plupart des gens cherchent une solution, un moyen pour progresser… Il faut faire des sacrifices pour cela, il n’y a pas de miracle. Lire un ouvrage sur un domaine qui nous intéresse ne peut pas être considéré comme un sacrifice. Le seul moyen d’apprendre, c’est par l’expérience, les erreurs. Apprendre, c’est aussi se former, à l’université ou dans d’autres institutions. Enfin, apprendre, c’est lire, se tourner vers la littérature qui ajoute une dimension en nous. Cet ouvrage a cet humble objectif

d’ajouter un petit quelque chose de plus dans le domaine du management de projet. Ce qui en sortira vous enrichira peutêtre d’une nouvelle information, peut vous paraître évident de prime abord, à moins que votre rythme de vie effréné actuel vous empêche d’y réfléchir ou encore de la mettre en pratique.

Un ouvrage tiré de faits divers et des expériences des autres « Pour apprendre, il faut une attitude active et non passive. C’est en nous exerçant que nous nous perfectionnons. Pour assimiler ces principes, mettez les

en actions, appliquez les chaque fois que l’occasion se présente. » Bernard Shaw C’est l’expérience qui accroît le savoir, pas les mots. C’est la pratique des entreprises, le vécu de mes collègues et de mes pairs managers de projet que j’ai essayé de capturer dans cet ouvrage. Lire l’expérience des autres peut être bénéfique. Lire, c’est comme vivre ces expériences soi-même et c’est paraît-il, le seul moyen de vivre plusieurs fois. En effet, lors des séminaires, congrès ou simple événement autour du management de projet, j’ai échangé pas mal d’idées autour du sujet et ces échanges sont aussi

capturés dans cet ouvrage. Au début, je vivais ces séminaires ou congrès sur le thème du management de projets, de programmes ou négociations comme un sacrifice de mon temps libre, un effort supplémentaire. Mais l’adage dit que, pour réaliser nos rêves, il faut passer par ce chemin-là. Je voulais tellement devenir expert du sujet que je faisais passer cet effort avant tout autre plaisir de la vie. Aujourd’hui, cela n’est plus le cas, c’est devenu un plaisir de participer à ces événements, c’est une rencontre avec moi-même et avec mes pairs, c’est un enrichissement personnel. Il y a une telle diversité dans les expériences des autres et cette diversité de la rencontre ne peut qu’être

enrichissante. J’ai toujours hâte de me rendre aux suivants et d’ailleurs, pas mal d’idées de cet ouvrage, sa substance-même proviennent de ces rencontres, des conversations avec ces personnalités extraordinaires. Pardonnez ma manière de m’exprimer, j’ai peutêtre perdu quelques idées en chemin. Certaines personnes naissent avec ces aptitudes, pas moi, j’ai dû faire beaucoup d’effort. « Être riche jusqu’à présent, c’était avoir. Être riche, désormais, ce sera appartenir à un réseau, développer des capacités d’appartenance. » Jacques Attali

En participant à ces événements, on croise des hommes et des femmes qui partagent le même enthousiasme sur le management de projet ou de programme : l’envie d’apprendre ce métier. Nous avons tous cette même quête : le désir de nous épanouir, de maintenir un réseau… C’est aussi l’occasion de prendre l’air et du recul en se rendant dans ces lieux différents de notre milieu professionnel, parmi d’autres personnes au contact desquelles progresser et se reconnaître. Lors de ces moments, on apprend souvent les dernières nouveautés du métier. Oui, certains congrès ou séminaires sont payants, mais vous ne perdrez jamais

votre argent en rencontrant des professionnels aux personnalités extraordinaires, surtout si vous désirez devenir un jour l’un d’entre eux, si vous désirez faire partie de ceux qui sont allés au bout de leurs rêves, ces managers de projets de grande envergure, auteurs de plusieurs ouvrages, keynote speaker, etc. Le retour sur investissement pour la suite de votre carrière est inestimable. Personnellement, pour ne citer que deux noms parmi tant d’autres, j’ai eu l’occasion de rencontrer et de dîner avec Gary R. Heerkens, auteur de plusieurs livres sur le management de projet, lors d’un congrès PMI® à Milan en 2010. J’ai aussi eu l’occasion

d’assister à un workshop et de pouvoir discuter avec Harley Lovegrove dont le parcours professionnel, pourtant dépourvu de formation universitaire, m’a fortement impressionné. Il a fait mieux à mes yeux que certains Centraliens. D’ailleurs, cet ouvrage est né d’une discussion avec Harley alors que je lui faisais part de mon dépit de ne pas trouver, dans la littérature française, de livre traitant de la mise en pratique d’une méthodologie standard internationale comme dans la littérature anglophone, et que j’aimerais tellement pouvoir conseiller un livre en français qui parlerait de ces méthodologies à ceux à qui j’enseigne le management de projet en France, il me répondit de

l’écrire et de le faire publier moi-même. Un ouvrage comme je désirerais qu’il en existe en français pour mieux parler de méthodologie en management de projet basé sur de la pratique, un ouvrage qui se voudrait être un « pense-bête », une boîte à outils et de techniques, que l’on peut appliquer tout de suite dans son quotidien de Manager de Projet, ou qui offre une idée pratique avec un cas concret du monde des projets et voici cet ouvrage. Ces moments sont incroyablement riches d’enseignements personnels et rencontres émouvantes. Je n’y ai pas rencontré la femme de ma vie, mais plutôt le job de mes rêves. Ce que

j’essaie de dire, c’est que si ces rencontres changent ne serait-ce qu’une seule chose en nous, c’est le regard que nous portons sur notre propre carrière, notre propre approche du management de projets, notre propre démarche pour faire face aux crises : elles donnent envie de nous aligner sur ce que nous avons entendu. Ces rencontres sont comme des miroirs qui nous renvoient à notre propre condition et situation, là où nous puisons notre force pour aller de l’avant. On dit que le contentement de soi et l’absence de participation d’un besoin socioculturel peuvent être des symptômes de déficiences personnelles et sociales. Le Manager de Projet doit toujours chercher à aller vers les autres,

ses pairs, ses collègues, en vue d’un enrichissement personnel. La relation avec les autres nous constitue comme être humain ; elle est comme le socle sur lequel chacun peut construire sa vie. Tout au long de notre existence, elle nous façonne ; c'est dans la relation que se joue une grande partie de notre vie. Combien de fois a-t-on rencontré des gens qui nous ont marqués ou ont marqué à vie notre parcours ? Nous avons tous des modèles, des héros, des hommes et des femmes que nous rêvons d’approcher au moins une fois dans notre vie. Eh bien, j’ai rencontré les miens dans des workshops où j’ai été convié, où je me suis moi-même invité, ou lors d’événements organisés par les

chapitres de PMI®.

La structure de l’ouvrage L’ouvrage se divise en plusieurs sections de la façon suivante : 1. Introduction : au cas où vous ne l’auriez pas remarqué, c’est ce que vous êtes en train de lire. Les raisons de cet ouvrage et l’intérêt de le lire ainsi que l’importance de faire partie d’un réseau de Manager de Projet. Merci de m’avoir lu jusqu’ici et j’espère que vous me suivrez jusqu’au bout. 2. Les sens, l’essence et les raisons d’être des projets : qu’est-ce qu’un projet ? Quelles sont les raisons

d’être d’un projet ? Certaines organisations savent-elles qu’on établit des projets pour économiser de l’argent ou, encore mieux, pour faire de l’argent et qu’en aucun cas il ne s’agit d’en perdre ou d’en gaspiller sur des projets peu rentables pour l’organisation ? Pourquoi se donne-t-on la peine d’établir un projet ? La définition réelle d’un projet et ses caractéristiques. Le mode de sélection ou la genèse des projets. Comment un projet peut-il être le levier pour atteindre les objectifs stratégiques d’une organisation ? 3. Le besoin de méthodologie: La

puissance est la méthode, disait Nietzsche. Pourquoi est-ce d’autant plus vrai pour le management de projet, quelle que soit la taille du projet ? Pourquoi l’utilité d’une culture de management de projet estelle si difficile à comprendre dans certaines organisations ? On s’attardera sur le rôle des Offices de Management de Projet (PMO) qui sont aux managers de projet ce que les tours de contrôle sont aux pilotes d’avion. En clair, les PMO, dépositaires de la méthodologie de l’organisation, évitent les collisions entre projets, autorisent le lancement d’un autre, guident le projet de sa phase initiale à sa phase de clôture,

donnent la priorité à un projet par rapport à un autre. 4. La science et l’art du management de projet : Cette section illustrera l’utilisation dans le cas pratique de la science du management de projet. L’ensemble des composantes de cette science sera discuté et illustré par des exemples concrets - les neuf domaines de connaissances (1Intégration du projet, 2- Scope, 3Délai, 4- Coût, 5- Qualité, 6Ressources Humaines, 7Communication, 8- Risques, 9Approvisionnement), les 5 groupes processus (1Initiation, 2Planification, 3- Exécution, 4-

Contrôle et Suivi, 5- Clôture) ou encore les outils et les techniques qui la composent. Le management de projet est l’art de déléguer et cela nécessite des compétences (soft skills).Cette section traite également des compétences requises pour manager un projet ou un programme. 5. Le bilan : Nous aurons fait le tour de la question sur le management de projet, alors, de quoi traiter ensuite ? Vous avez réussi un projet et vous désirez poursuivre, vous avez manqué un projet et vous désirez ouvrir un bar, vous voulez devenir Manager de Projet… Ce dernier chapitre traite des perspectives de

développement de carrière dans le management de projets ou de programmes. Il évoque aussi la question du crédit accordé à celui qui désirerait postuler au poste de Vice-Président (VP) après le management de projet. J’ai connu des entreprises où le Manager de Projet s’est fait un nom après avoir raté un projet, et a même obtenu une promotion : VP.

Caractéristique de l’ouvrage L’ouvrage a pour objectif de fournir des informations pratiques sur le management de projet. Pour ce faire, des signes ont été conçus afin que le lecteur puisse repérer plus rapidement les sujets qui l’intéressent. Signe Signification Définition : ce signe se réfère à la définition d’un mot, qui est souvent celle référencée dans le PMBoK® (Project Management Book of Knowledge) de PMI.

Exemple : ce signe se réfère à des exemples qui sont issus de cas concrets pratiques ou à des templates prêts à être utilisés au quotidien Loi : ce signe se réfère à des lois qui portent souvent le nom de ceux qui les ont créées. Le management de projet obéit à quelques lois. Technique : ce signe se réfère à une technique, souvent issue du PMBOK®. Je rappelle que le management de

projet est l’application de ces techniques. Outil : ce signe se réfère à un outil, souvent issu du PMBOK®. Je rappelle que le management de projet est l’application de ces outils. Processus : ce signe se réfère à un processus, souvent issu du PMBOK®. Le management de projet nécessite le management efficace de processus appropriés.

Ceci n’est pas un énième cours théorique, qui peut plonger le lecteur dans un coma profond, mais davantage un livre pour éveiller son côté acteur. C’est un ouvrage d’action, livrant de nombreuses études de cas pratiques. L’homme est un être de relation qui n’accède à lui-même que s’il est interpellé par l’autre. L’ouvrage n’est pas un bréviaire ni une « leçon » ; je n’aime pas ce mot car il peut évoquer, sur un ton condescendant, que c’est là le seul chemin, comme si j’étais détenteur de la vérité sur le management de projet. Plusieurs méthodologies existent et elles se valent toutes : il ne faut pas oublier

que la seule méthodologie qui compte est celle qui marche, « whatever works » disent les Anglais, en respectant l’éthique de la profession. L’objectif de cet ouvrage, qui est aussi un livre d’action, est également d’interpeller le lecteur, qu’il soit CEO, étudiant, employé ou Manager de Projet confirmé. Au travers de ce livre je vous invite à vous interroger sur l’existence, au sein de votre organisation, d’une telle culture de management de projet, je vous invite à découvrir ou à revoir des connaissances, à confronter vos idées par rapport à la situation donnée : qu’aurait entrepris le lecteur dans un cas ici présenté ? Comment auriez-vous appliqué telle ou telle technique dans

votre quotidien ? Gardez-les à l’esprit pour pouvoir les appliquer automatiquement sans efforts. Traduisezles en actions, appliquez-les chaque fois que l’occasion se présente. Il faut faire partie de ceux qui n’attendent pas la prochaine occasion pour agir. Le moment de faire ses preuves, c’est maintenant ! Surtout, ne pas suivre la voie de ceux qui travaillent sur un projet et préfèrent croire qu’ils feront mieux sur le suivant, ou celle de ceux qui sont éternellement en attente de la mission idéale ou du projet idéal. Cela n’arrive jamais. Sans réserve, il faut s’y mettre et prendre les choses en mains dès maintenant. Apprendre une nouvelle langue, un nouveau sport ou n’importe

quelle méthodologie suppose de l’application, de la rigueur et de la discipline. A vous, lecteur ou organisation, de trouver le moyen d’implémenter efficacement la méthodologie de management de projet qui vous convient. J’espère juste que cet ouvrage pourra vous être utile et en inspirer certains. J’espère que vous serez de ceux qui penseront, comme moi, que le management de projet est plus qu’un métier, que c’est une façon de vivre.

SECTION 2 Essence et Sens des Projets La compréhension du mot « projet » constitue la base du management de projet. Cependant, ce terme est aujourd’hui associé à tout et n’importe quoi, en particulier dans les organisations sans culture du management de projet. Vous n’êtes pas

convaincu ? Faites donc le tour des bureaux en demandant à vos collègues de définir le mot « projet ». Les réponses pourraient vous surprendre. Or, sans connaître les caractéristiques ou la genèse d’un projet, il est difficile d’en manager. Pour cette raison, l’objectif de cette section est de déterminer l’essence, les sens et les raisons d’être d’un projet. « Un homme sans projets est l'ennemi du genre humain » Roger Nimier

Patchwork - Un tour ensemble (pot-pourri) sur les idées reçues concernant les projets Qu’est ce qu’un projet ? Telle est ma première question aux auditeurs des formations que je dispense. À chaque fois, je reçois autant de définitions qu’il y a de participants. Par exemple, le premier de classe me répond toujours, sur le ton si caractéristique du pédant étalant ses connaissances, que les projets ont des buts et des objectifs clairement exposés afin de produire des résultats bien définis et qu’ils sont toujours

accompagnés de la même constante : la satisfaction d’un besoin spécifique. En bon auditeur, il ajoute ensuite qu’un projet est progressivement élaboré, le résultat final étant spécifié et développé tout au long de sa réalisation, de même que les objectifs sont uniquement énumérés en son début, puisqu’ils seront élaborés et définis de façon plus précise au fur et à mesure de sa progression. “Les choses les plus belles sont celles que souffle la folie et qu’écrit la raison. Il faut demeurer entre les deux, tout près de la folie quand on rêve, tout près de la raison quand on écrit. » André Gide

Certains participants ayant le goût du romanesque me répondent qu’un projet est l’idée de se projeter vers l’avant, de transformer les visions, même les plus folles, en un but à atteindre. Entreprendre un projet, c’est vivre ses rêves au lieu de les rêver. Et c’est précisément lorsqu’on passe à l’action qu’on commence à entreprendre un projet. Des exemples ? La tour métallique « haute de plus de mille pieds » construite en centre-ville par Eiffel à l’aube du XXe siècle, ou encore les premiers pas de Neil Armstrong et Buzz Aldrin sur la Lune en 1969, constituaient des idées assez folles pour leurs époques respectives. Plus

récemment, Marc Dufeil, devenu tétraplégique, a vu son rêve se concrétiser à force de ténacité: le projet de construction d'un catamaran adapté à son handicap pour réaliser un tour du monde, ainsi que la promotion de l’éconavigation. En ce qui me concerne, l’idée d’écrire cet ouvrage m’est venue de l’envie de voir exister un livre grâce auquel on apprendrait le management de projet par la pratique et les exemples. Les réponses plus classiques définissent un projet comme un ensemble d’activités auxquelles on s’adonnera ou qui seront exécutées par les spécialistes de chaque discipline impliquée. Certains se lancent alors dans une

véritable démonstration en postulant qu’un projet n’est autre que la solution à un problème identifié par le Business et dont l’unique objectif est la résolution de cette complication. Selon eux, on peut considérer un projet comme accompli et réussi lorsque le problème pour lequel il a été créé est résolu. Et, plus question de plaisanter, les démonstrateurs devenus tribuns continuent d’argumenter à coups de citations, se référant à Einstein selon qui « un problème sans solution est un problème mal défini ». Alors que je me préparais à répondre qu’un problème mal défini peut aussi suggérer un nombre infini de solutions, une « démonstratrice » continua en affirmant que pour réellement trouver une réponse

à ce problème entier, il faudrait une analyse approfondie préalable des besoins à partir desquels on pourrait suggérer une ou plusieurs solutions. « S'il n'y a pas de solution, c'est qu'il n'y a pas de problème » Un anonyme Et, insista-t-elle, il conviendrait surtout d’éviter l’effet papillon postulant qu’un changement mineur dans la définition du problème est capable d’engendrer des conséquences considérables sur la solution à implémenter. Elle suggéra alors de surmonter l’obstacle en s’accordant sur le problème avant d’entamer sa résolution, afin de ne pas

éradiquer l’un des symptômes, mais bien la complication toute entière. La « démonstratrice » termina son soliloque en affirmant que l’un des facteurs d’échec d’un projet est la mauvaise définition de la solution au problème en question. Je me demandais si je ne devais pas lui proposer de donner le cours à ma place…

Figure 2: Pont Rajeev Ghandi

Problème mal défini: le pont à Bendra et Worli à Bombay Objectif du projet : la c chef-d’œuvre en termes banlieues de Bombay par la mer, afin d minutes pour une distance de huit k solution aux problèmes de congestions Mombay. La réduction du trajet devait temps gagné dans d’autres activité l’économie locale et au pays entier. L’ob stress et d’améliorer ainsi la qualité d concernées. Cependant, selon The Eco défini et la congestion s’est vue déplacé ne remporte donc pas un franc succès, construction a accusé un retard de cinq l’Inde cinq fois plus que le budget allou

Exemple 2: Problème mal défini

J’entends également des réponses plus laconiques, dont les énonciateurs arguent que les projets visent un changement bénéfique à l’organisation ou un changement économique et social durable, la preuve étant la création du transistor, véritable révolution mondiale. L’auditeur conclut alors qu’un projet est un vecteur de mutation positive. Quelques poètes dans l’audience me

renvoient à des métaphores, comparant les projets à des courses de voitures, possédant un début et une fin déterminés, et passant par des jalons (milestones) comme lors d’arrêts au stand. Le Manager de Projet n’est alors autre que le directeur d’écurie chargé de diriger la compétition (comprenez le projet) et décisionnaire de la stratégie (du management) dès le début de la course.

Figure 3: un projet est comme une course de voiture

Tout au long de la compétition, le directeur d’écurie contrôle et anticipe

les problèmes et à chaque arrêt, stand ou milestone, on fait le point : a-t-on suffisamment d’essence ou de budget pour continuer et atteindre les objectifs ? Est-il nécessaire de changer les pneumatiques ou autres ressources pour terminer la course ? En somme, on procède au management à chaque étape ou milestone. Cette explication est interrompue par un étudiant désireux de comprendre pourquoi, si tout est contrôlé et managé à chaque étape pour que les escales restantes se déroulent bien, Jean Alési lors des Grands Prix d’Autriche en 1999 et d’Australie en 1997 est tombé en panne d’essence. Outre les poètes, quelques comiques assistent visiblement à mon cours…

Alors, s’agissait-il de management « au petit bonheur la chance » ? Quand les changements de pneus ou les ravitaillements se déroulent mal, est-ce dû à un mauvais management du directeur d’écurie ou à son équipe ? Quand un projet accuse des problèmes, la faute vient-elle du manager ou du manque de formation ou de pratique de son groupe? Le directeur d’écurie a-t-il mal managé ses étapes ou bien sa ressource (le pilote) ne l’a-t-elle pas assez écouté ? Viaduc de Millau: exemple de projet qui vise un changement économique et social durable Ce projet à 320 millions

d’euros, construit en 3 ans, est actuellement le pont le plus haut du monde, un record que peut également enregistrer son ensemble pile-pylône. Ce viaduc a permis de développer les activités commerciales et industrielles de la région Aveyronnaise et suscite des vagues de tourisme. Sa construction a également éveillé l’intérêt de nombreuses personnalités politiques. Exemple 3: Projet qui vise un changement économique et social

Un projet qui échoue parce qu’on ne peut plus lui consacrer le budget nécessaire peut-il être le résultat d’une mauvaise communication entre le Manager de Projet et son équipe ou bien s’agit-il simplement de mauvais

management? Plus souvent qu’on ne l’imagine, des projets se voient abandonnés comme une voiture arrête la course pour plusieurs raisons : un manque de budget (tout comme une panne d’essence) ou la soudaine inutilité du projet, par exemple. Que penser de la réponse de cet auditeur selon lequel un projet implique un groupe d’activités interdépendantes, planifiées et exécutées selon une certaine séquence afin de créer un produit unique ou un service dans un délai précis, dans le but de réaliser des bénéfices ? Puis tour à tour, j’entends qu’un projet

est limité dans le temps ou encore qu’un projet nécessitera toujours un financement. Puisque les images valent parfois mieux qu’un long discours, voici la photo qu’un auditeur propose afin d’illustrer le mot « projet »:

Exemple 4: Projet avec durée et budget

En rejoignant les autres auditeurs, il ajoute ensuite qu’un projet est doté

d’une durée, d’un début et d’une fin définis, ainsi que d’un budget. Enfin, j’ai rappelé que selon le PMBOK® le projet est un moyen utilisé pour réaliser le plan stratégique d’une organisation. Alors, laquelle de ces définitions est correcte ? Les réponses de ces auditeurs se révèlent en fait toutes exactes. Que reste-il dès lors à enseigner ? Avant de se concentrer sur une véritable définition, il convient d’aborder quelques caractéristiques de projets importants qu’il est bon de garder en mémoire. En effet, la connaissance de ces spécificités aide à la compréhension

de la définition et des sens d’un projet, et facilite ainsi son management.

Un projet est avant tout du Business avec un retour sur investissement (ROI) positif

En vérité, les projets sont avant tout du Business, et non de la technologie. Leur objectif fondamental

est l’obtention d’un résultat dont le Business pourra être le bénéficiaire : la diminution de certains coûts ou l’augmentation des revenus. Certaines compagnies perçoivent uniquement les projets comme une solution à des problèmes ponctuels, tandis que d’autres les considèrent comme le véritable levier de leurs productivités. Quoi qu’il en soit, l’objectif ultime est très simple : faire de l’argent ou en économiser en réduisant certains coûts, d’où l’importance de mesurer attentivement le fruit de chaque euro investi dans le projet. Cela s’appelle le retour sur investissement ou ROI (Return on Investment). Le ROI est un concept

encore mal compris et mal utilisé par les organisations. Il s’agit du lien entre le management de projet et les objectifs du Business, les projets représentant des investissements financiers issus du Business. Si un projet ne génère pas de ROI, il ne doit tout simplement pas voir le jour, puisqu’il est lancé dans le but de récolter de l’argent ou d’en économiser. Cela explique que tout projet requière un calcul du ROI, ce que certaines organisations-dont on se demande si elles devraient se réclamer à but lucratif- tendent à oublier, continuant à gaspiller de l’argent sur des projets qui ne leur rapportent pas le moindre centime.

Figure 4: Retour sur Investissement (ROI)

Un projet doit toujours répondre aux objectifs stratégiques du Business dans une organisation. Or, qui dit « Business » dit aussi « profit ». Le ROI est l’outil qui mesure la performance d’un projet et chaque organisation se doit de savoir au bout de combien de temps elle commencera à tirer des bénéfices de celui qu’elle planifie de lancer. Tout d’abord, il s’agit d’investir de l’argent pour entreprendre le projet en question, avant de déterminer le délai de récupération de cette somme. Passé ce seuil de rentabilité, l’organisation commencera à récolter le fruit de son investissement (voir Figure 1: Retour

sur Investissement). Cependant, si un projet ne peut accéder à son seuil de rentabilité que passé quatre ou cinq ans, ou pire, s’il n’a aucune chance de l’atteindre, mieux vaut ne pas le mettre en marche. Demandez toujours le résultat du calcul du seuil de rentabilité à ceux qui vous proposent la responsabilité d’un projet afin de déterminer s’il est voué à l’échec, car autant travailler sur un projet qui rapporte. En effet, les organisations comparent les projets via leurs ROI et si le vôtre est négatif, cela risque fort de vous dévaloriser à leurs yeux, ce qui est négatif pour le développement de votre carrière.

ROI positif du projet 1 Dollar 1 pixel: Tout le monde gardera à l’esprit le projet d’Alex Tew. À 21 ans, il lança son site Internet en espérant collecter suffisamment d’argent pour financer ses études, refusant d'entrer dans la vie professionnelle criblé de lourdes dettes. Alex Tew investit donc un montant dans son projet et généra des revenus d’une manière simple : en vendant chaque pixel de sa page d’accueil au prix d’un dollar à tout compagnie désireuse d’y apposer son logo. En quelque mois, il mesura le succès de son projet par un ROI estimé à un million de dollars US : son pari était remporté. Pour information, Amazon (fondé en 1994) a seulement commencé à

dégager du profit en 2001, tandis que Ryanair (créé en 1985) a perçu ses premiers bénéfices en 1995. Si pour certains le ROI est immédiat, pour d’autres il requiert donc beaucoup de patience. Pour preuve, le stade de Wembley (projet à £800 Millions) ou encore le Millenium dôme à Londres (projet à £43 Millions) sont des projets dont le ROI est discuté au quotidien dans les journaux anglais. Mais cela ne signifie aucunement qu’il faille s’entêter. Car, comme le disait si bien Einstein, « la folie, c’est de continuer à faire la même chose et attendre des résultats différents. » Exemple 5: ROI positif

Il est d’ailleurs de notoriété publique

que les entreprises considèrent davantage les managers de projet à qui elles doivent la réussite des projets qui rapportent le plus d’argent. On a tendance à confier les responsabilités à ceux qui ont fait d’un projet qui rapporte à l’entreprise un succès. De même, leur mémoire devient soudainement très courte lorsqu’il s’agit de se rappeler ceux qui ne leur ont rien rapporté, ou pire, ceux qui ont raté leurs projets, alors perçus comme une source de dépenses et de gaspillage. Vous voulez un bon conseil ? Rendez-vous dans une organisation où l’on saura vous apprécier à votre valeur et où l’on n’insultera pas votre intelligence en vous confiant des projets qui ne

rapportent rien ou qui sont voués à l’échec. Ton destin dépendra de ta réputation. Dans toute organisation, le Manager de Projet qui gagne a toujours raison et on l’entoure de mille soins, celui ou celle qui perd a toujours tort et se retrouve vite lâché(e). On peut se retrouver très rapidement être le mouton noir au milieu du troupeau blanc. « Chaque fois que vous voyez une entreprise qui réussit, dites-vous que c'est parce qu'un jour quelqu'un a pris une décision courageuse » Anonyme

Qu’est-ce qu’un projet

réussi? Un échec survient lorsque l’on n'arrive pas à ses objectifs. Si on considère tout désir que l’on parvient à satisfaire comme étant un succès, alors on peut qualifier tout projet dont les buts sont atteints de « succès ». Si le cas survient, il convient en tout cas d’en tirer de la satisfaction et de savourer le moment. Or, j’ai constaté que peu d’équipes célèbrent leurs victoires. C’est un tort, mais ce n’est pas le sujet pour l’instant, la question étant plutôt la suivante : comment définir un projet réussi ? Sur un plan personnel, on peut se dire que le projet est une réussite parce qu’on n’a pas été licencié, ou que cela n’a pas fait la Une des journaux, ou encore que

personne n’en parle. Cela vérifie alors l’adage : « pas de nouvelles, bonne nouvelle. » On peut être animé d’un sentiment de fierté et de satisfaction face au « devoir accompli » en livrant les objectifs du projet. On peut se réjouir de la collaboration réussie où le travail d’équipe a marché. On peut également se réjouir que chacun des membres de l’équipe projet ait pris sa responsabilité dans l’intérêt du collectif. Et ce sont autant de succès personnels. Mais d’un point de vue organisationnel, le succès d’un projet peut être mesuré de différentes façons.

Succès mesuré à partir de la valeur créée pour le Business

Peut-on considérer un projet livré dans les délais et dans les budgets impartis comme un succès ? On peut certes féliciter le Manager de Projet pour son travail, mais que faire si le projet livré n’est plus utile? S’il ne fournit plus la valeur espérée par le Business, pour laquelle il a été lancé ? À notre époque, tout change à une vitesse fulgurante, et une valeur attendue lors du lancement de projet peut rapidement ne plus être à l’ordre du jour. C’est alors que, même si le Manager de Projet a correctement travaillé et livré des résultats correspondants aux délais et au budget, le projet entier est à jeter. De plus, qui dit « gaspillage » dit aussi « échec ».

Jeff Berman, dans son ouvrage Maximizing Business Value, définit le succès comme suit:

La valeur créée pour le Business par le projet correspond à l’un des objectifs stratégiques du Business. S’il n’est pas atteint, la valeur espérée par le Business équivaut à zéro, et il en est alors de même pour le projet, aussi excellent et respectueux des délais et des budgets qu’ait pu se montrer le Manager de Projet. Le ROI est l’un des outils qui mesure la valeur créée par le projet pour le

Business. Il calcule donc également le succès du projet en fonction de l’augmentation des revenus du Business ou encore de la baisse des coûts. Un projet livré au-delà des délais et des budgets impartis peut donc encore être considéré comme un succès si son ROI peut toujours être positif et apporter la valeur espérée par le Business. Galileo : Un projet à 3,4 milliards d’euros accusant un retard de cinq ans par rapport au calendrier initial peut il encore livrer de la valeur ? Galileo, dont le lancement des deux premiers satellites est prévu en avril 2011 (s’il n’est pas à nouveau postposé), peut

toujours livrer la valeur pour laquelle il a été lancé. Ce projet, futur système européen de localisation par satellite, a été conçu pour concurrencer le GPS américain. Il garantira l'autonomie de l'Union Européenne vis-à-vis des USA dans de domaines stratégiques tels que les applications militaires. Exemple 6: Projet avec retard et au-delà du budget pouvant rencontrer un ROI positif

Le ROI se mesure une fois le projet livré, mais se définit bien avant son lancement, durant sa phase de sélection. Or, certaines organisations entreprennent des projets « au petit bonheur la chance », sans démontrer en amont la

valeur pour le Business au moyen d’un calcul du ROI et d’un Business Case solide. Ces entreprises perdent beaucoup d’argent car elles ne peuvent plus recouvrer ce qui a été investi. La valeur créée pour le Business est donc la garantie de succès du projet et doit en représenter le but ultime. J’ai côtoyé énormément d’entreprises qui sabraient le champagne dès la signature du contrat d’un projet de quelques millions, tandis qu’elles n’avaient pas encore évalué en interne et de façon approfondie, que ce soit par l’intermédiaire d’un Business Case ou d’un calcul de ROI, si le projet pouvait livrer des bénéfices et à partir de quel

moment. Lorsqu’elles se rendaient compte du coût de réalisation réel du projet, elles en venaient toujours à se demander pourquoi elles l’avaient lancé. En effet, au fur et à mesure de sa réalisation, le projet ne se révélait réalisable qu’accompagné de coûts exorbitants, tandis que le retour sur investissement approchait le zéro. Mais le pire dans cette histoire, est que dans 100% des cas, ces compagnies s’entêtaient toujours à réaliser le projet, soucieuses de ne pas perdre la face. De plus, puisque personne ne prenait la responsabilité de stopper net l’aventure, le gaspillage continuait. Ainsi, chaque organisation devrait mettre en place un mécanisme capable d’arrêter tout projet

qui ne livre plus la valeur attendue, s’il ne respecte plus les objectifs stratégiques du Business. Le groupe Standish, dans son Chaos Manifesto 2009, recommande pour tout projet représentant un grand risque la mise en place d’un Kill Switch : un interrupteur capable de déclarer le projet en mode « fin de vie » ou « mort ». En effet, Standish estime qu’on devrait prédéterminer pour chaque projet un stade à partir duquel il n’est plus raisonnable d’y engager des investissements. Cet interrupteur serait alors activé dès que les jalons ou les objectifs du Business ne seraient plus rencontrés, afin d’empêcher le projet de

continuer sa marche vers une mort certaine. La décision d’arrêt serait alors irrévocable. D’ailleurs, un Manager de Projet devrait avoir le courage de conseiller la mise à mort de son projet si celui-ci ne répond plus aux objectifs stratégiques du Business, ou du moins de donner son opinion à tous les décideurs de l’organisation, comme par exemple au comité de pilotage (steering committee). Puisqu’on vous a confié les clefs du camion, ne l’abandonnez pas en route, mais conduisez-le à destination et parquez-le correctement, que ce soit vers la tombe ou vers la vie. A ce propos, avez-vous regardé le nombre de projets qui figurent au cimetière de votre compagnie ? S’il est élevé, cela signifie

que votre organisation est dotée d’une culture de management de projet. En effet, une organisation qui sait tuer les projets qui ne rapportent plus est plus mature. “Chaque fois que vous voyez une entreprise qui échoue, dites-vous que c'est parce qu'un jour quelqu'un n'a pas pris une décision courageuse” Anonyme

Succès mesuré à partir de la satisfaction du client Les groupes de personnes qui reçoivent ou qui vont être amenés à utiliser le résultat, le service ou le

produit livré par un projet sont les clients. Ils sont d’une grande importance, puisque la réussite d’un projet se mesure également à l’aune de leur satisfaction. Il est donc crucial de manager correctement leurs attentes en termes de coûts, de temps, de qualité ou de fonctionnalité. La déception est la différence négative entre attentes et réalité, et la satisfaction est la différence positive entre les attentes et la réalité : Si attentes – réalité < 0, alors déception des utilisateurs, le projet n’a pas livré ses promesses Si attentes – réalité = 0, alors, satisfaction des utilisateurs, le projet a livré exactement ses promesses

Si attentes – réalité > 0, alors, satisfaction et excitation des utilisateurs, le projet a été livré au-delà de ses promesses Dans le monde compétitif d’aujourd’hui, le triomphe des projets est la clé du succès d’une organisation. Une entreprise sachant livrer des projets qui satisfont ses clients se porte très bien et dégage une grande part de marché. Projet iPad d’APPLE - Projet à succès avec une grande satisfaction du client L’objectif du projet de l’entreprise de Steve Job était de produire une tablette

électronique orientée vers les médias tels que les livres, les journaux, les magazines, les films, la musique et les jeux ; mais également vers l'Internet et l'accès au courrier électronique. Le projet a remporté un franc succès auprès des clients puisqu’un million d'iPad a été vendu seulement en l’espace mois. Exemple 7: projet à satisfaction du client

En revanche, une organisation qui ne sait pas livrer des projets de bonne qualité ni dans les délais, ni dans les budgets alloués, risque de mécontenter le client. Or, l’adage veut qu’un acheteur déçu racontera son expérience à dix personnes, tandis que le chaland satisfait n’en fera écho qu’à trois individus. Lors

de chaque livraison d’un projet, l’image de l’organisation est donc rapidement mise en péril. Un client satisfait reste fidèle, au contraire d’un client insatisfait qui risque d’aller voir ailleurs si le ravissement de ses attentes ne s’y trouve pas. Or, les enjeux économique et financier tirés de la satisfaction ou de l’insatisfaction des clients sont considérables : dans le premier cas (un projet à satisfaction positive), le business continue avec l’acquéreur. Dans l’autre cas (un projet à satisfaction négative), dans le meilleur des scénarios, l’organisation devra engager des coûts supplémentaires pour pallier à la déception du client. Ces coûts supplémentaires comprennent les coûts

des retours, du retravail, des remises et des remplacements de matériel. Souvenez-vous de Toyota, obligé de rapatrier des millions de véhicules afin de les réparer. Dans le pire des cas, l’organisation risque carrément de perdre le client, ce qui représente un dégât financier à la valeur des contrats actuels, proches ou futurs dès lors compromis. L’organisation se verra subséquemment dans l’obligation d’engager des dépenses supplémentaires en temps et en argent, afin de compenser la perte du client et de débusquer d’autres acheteurs. Ainsi, il est dans l’intérêt des organisations de livrer des projets en

mesure de satisfaire le client. Pour ce faire, il ne tient qu’à l’entreprise de mettre en place les bonnes méthodologies permettant l’amélioration significative de la performance, en mesurant tout type de processus à la lumière des attentes du chaland. Introduction de Six Sigma chez General Electric (GE) pour améliorer la satisfaction du client Le "Six Sigma" est une méthode qui permet de mesurer statiquement la performance actuelle d'un produit ou d'un service et de rechercher les solutions pour renforcer la satisfaction de la clientèle. Jack Welsh, dans son livre

Winning, a classé Six Sigma parmi les quatre révolutions qui ont changé GE à égalité avec celles des services de l'e-business et de l'internationalisation. Selon l’édition de Mars 2010 de Business Digest, au cours des cinq premières années de sa mise en place, le Six Sigma a permis à GE d’économiser environ cinq milliards de dollars. Le concept de Six Sigma est devenu un mythe par la grâce du légendaire patron de General Electric : Jack Welch. Exemple 8: Méthodologie pour améliorer la satisfaction du client

Un projet avec un bon impact économique, social ou environnemental

L’impact du projet est souvent plus long que sa durée de réalisation. Un projet rencontre un succès lorsqu’il obtient un impact social, économique ou environnemental. En somme, un projet à succès apporte toujours une amélioration, un changement bénéfique. Autrement, il ne doit pas exister. Projet avec un impact social, économique ou environnemental Microcrédit au Bengladesh : Le projet Grameen de Muhammad Yunus, surnommé « le banquier des pauvres », était d’offrir aux plus démunis un accès à des capitaux, en proposant un micro-crédit. Cela eut

un impact immédiat sur les plans social et économique, d’abord au Bengladesh, ensuite dans le monde entier, ce qui a d’ailleurs valut à Yunus de décrocher le prix Nobel d’économie. Les projets intégrés du Sixième Programme Cadre de la Commission Européenne : Ces projets ont pour objectif de favoriser la compétitivité européenne et d’aider à la résolution de problèmes sociétaux majeurs. Par exemple, le projet AMMA, dont le but était d’améliorer notre compréhension de la mousson d’Afrique de l’ouest et de ses conséquences sur les environnements physique, chimique et biologique à l’échelle régionale et

mondiale, a eu un impact socioéconomique et sur la santé en Afrique de l’Ouest. Exemple 9: Projet à succès avec un impact social, économique ou environnemental

Pyramide du succès d’un projet à cinq niveaux Lors du congrès de PMI® à Milan en 2010, s’est tenu un workshop concernant les outils et techniques utiles pour manager un projet. J’y suis entré en grande discussion avec Gary R. Heerkens sur la mesure du succès d’un projet au sein d’une organisation. Pour l’illustrer, Gary établit une pyramide à cinq niveaux, comme le fait Maslow avec les besoins.

Figure 5: Pyramide de succès d'un projet

Niveau 1 : On s’intéresse à la performance d’un projet : est-il livré dans les temps ? Entre-t-il dans les budgets impartis ? Les qualités et fonctionnalités attendues ont-elles été respectées ?

Niveau 2 : On s’intéresse à l’efficience du projet, à la manière dont il a été managé. L’art et la science du Manager de Projet sont directement évalués à ce niveau. Niveau 3 : On tente de déterminer l’efficacité du projet : a-t-il atteint ses objectifs fonctionnels ? Le problème pour lequel il a été lancé est-il résolu ? Si les utilisateurs finaux du projet déplorent le résultat, l’efficacité est faible. En revanche, si leurs feedbacks sont bons, les fonctionnalités attendues ont été correctement livrées.

Niveau 4 : On observe l’impact du projet (ROI) : a-t-il atteint les objectifs stratégiques du Business ? Peut-il toujours livrer les valeurs espérées ? Niveau 5 : On vise l’amélioration de l’organisation : tout projet amène à une amélioration des processus dans une entreprise. Par exemple, l’équipe en charge du projet a-t-elle documenté les leçons inculquées? Je détaillerai les trois premiers niveaux dans les paragraphes à venir, puisqu’ils figurent au cœur de cet ouvrage. Le niveau 4 vient d’être défini en détails dans les paragraphes

précédents. Parlons alors du niveau 5. On peut aisément rencontrer des organisations qui n’apprennent ni de leurs erreurs, ni de leurs succès. Or, une entreprise qui est continuellement en train de s’instruire et d’améliorer ses processus et procédures, est une organisation qui accorde de l’importance au succès.

Template pour capturer les le sur un projet Ce qui a Ce qui n’a Re fonctionné pas fonctionné Planification du projet Contrôle et suivi du projet

Acquisition et utilisation des ressources Management de l’équipe projet Communication Management des risques Management du contrôle des changements Management des problèmes (issues) Formation Management des vendeurs et des contrats

Définition des exigences Quelles sont les trois leçons-clés qui peuve 123Selon vous, quels sont les trois domai nécessitant réellement une amélioration ? proposez-vous ? 123Selon vous, quels sont les trois aspects q de ce projet ? 123Dans l’ensemble, le projet a-t-il rempli Génère-t-il déjà des bénéfices anticipés ? -

Le scope du projet a-t-il été correctemen spécifications ont-elles été respectées? Avez-vous quelque chose à ajouter ? Exemple 10: Template pour capturer les leçons apprises sur un projet

Et pour qu’un projet aboutisse réellement à une victoire et qu’on en récolte vraiment du profit, il est nécessaire d’en tirer des leçons via un feedback. Cependant, de nos jours, les entreprises se concentrent le plus vite possible sur le prochain projet, sans prendre le temps d’apprendre grâce aux erreurs du passé.

Dans les facteurs environnementaux de toute entreprise, on devrait donc trouver une base de données qui contienne l’historique des projets et surtout, un document nommé « leçons tirées du projet qui vient d’être livré ». Ainsi, à chaque fin de projet, le Manager de Projet constituerait ce document. Pour ce faire, il disposerait de trois solutions : soit une réunion de tous les acteurs concernés, soit une interview individuelle de chacune des parties prenantes, y compris les membres de l’équipe projet, soit la distribution d’un template. Cependant, dans ce dernier cas, le

Manager de Projet devrait rendre compte des succès et échecs du projet, ainsi que des améliorations à apporter dans le futur. Ce genre de document est utile à toute organisation qui souhaite s’améliorer. Chaque Manager de Projet sur le point de débuter un projet aurait alors à fouiller dans cette base de données historique afin de s’en inspirer et d’éviter ainsi de commettre les mêmes erreurs que précédemment.

Statistiques sur les succès des projets de 2000 à 2009 Puisque les faits sont souvent plus éloquents que les mots, observons les statistiques effectuées par le Groupe Standish International sur les taux de

succès des projets IT de 2000 à 2009 (Figure 6: Taux de succès des projets IT). Celles-ci démontrent que les projets considérés comme des succès ne dépassent même pas les 35% chaque année, de 2000 à 2009. Dans le contexte qui nous occupe, un projet est défini « à succès » s’il a été livré dans les délais et qu’il ne dépasse pas les budgets impartis avec les caractéristiques requises. Le fait que je viens d’observer parle de lui-même : les organisations nécessitent davantage de culture de management de projet.

Figure 6: Taux de succès des projets IT (Extrait du "The Standish Group, Chaos Summary Report 2009)

Dans son rapport, le Groupe Standish International explique également que la

probabilité de réussite diminue considérablement à mesure que la taille du projet augmente. Plus spécifiquement, 61% des projets qui ont coûté moins de $ 750,000 se sont vus couronnés de succès, tandis que seulement 2% de ceux dont le coût dépassait $ 10 millions ont été une victoire. Ainsi, chaque organisation aurait tout intérêt à classer ses projets par tailles et à définir une méthodologie de management de projet adéquate en fonction de ce critère.

Taille de Projet Succès Plus de 10M$ 0% 6M$ - 10M$ 6% 3M$ - 6M$ 13% 750k$ - 3M$ 19% <750k$ 62%

Discutable 11% 20% 36% 18% 15%

Ech

Tableau 1: Taux de succès des projets IT par taille (Source: Chaos Summary Report 2009 du Standish Group)

Si les projets peuvent être classifiés par tailles, comment déterminer cellesci? On dit souvent que la taille n’est pas importante. Mais comme nous venons de nous en apercevoir (Tableau 1: Taux de succès des projets IT par taille), plus la taille du projet est grande, plus il y a de risques qu’il échoue. La complexité des projets ne peut que créer une confusion et des surcoûts que nous essayons pourtant tous d’éviter. Une entreprise peut avoir une pléthore de projets, des petits comme des mégaprojets, en passant par des projets

de taille moyenne. Mais détermine-t-elle une approche spécifique pour le management de chaque projet ou en possède-t-elle des différentes, qu’elle choisit d’appliquer en fonction de la taille ? Encore faut-il savoir classifier ses projets… Dans votre organisation, comment les groupe-t-on? En fonction des coûts investis ? Du nombre de ressources utilisées? Du délai imparti ? La taille de chaque projet peut être basée sur sa complexité, son importance politique et stratégique, son coût total, la taille et le niveau de l’équipe projet, le degré de changement que le projet peut créer, etc. Chaque organisation doit

établir une définition de la taille. L’entreprise qui dispose déjà d’une culture de management de projet possède sa propre façon de classifier les typologies de projets et la méthodologie de management de projet en fonction de sa taille. Je vous l’accorde, la construction du plus haut gratte-ciel au monde (le Burj Dubai) est un mégaprojet de huit années qui a nécessité un budget de 4,1 milliards de dollars américains et le travail de 12 000 ouvriers. En tous cas, si vous connaissez la taille de votre projet, vous pourrez déterminer les bons processus à utiliser afin de le réaliser avec succès. On a beau inventer et découper les critères de sélection et

essayer de les objectiver au maximum, il arrive nécessairement un point où il faut jouer arbitraire et déterminer si ce projet est petit, grand, large ou extra large. Vous trouverez ci-dessous une tentative de définition de la taille des projets. Cependant, je rappelle qu’il est indispensable de se donner des balises personnalisées selon l'organisation si l’on veut manager les projets proprement et les réaliser avec succès. La taille du projet donne une indication sur le type de management de projet à adopter.

Typologie de projet par le budget Rien n’empêche une entreprise de classifier ses projets par budgets, et de définir un guide de management de projet pour chaque taille de projet, comme le montre l’exemple ci-dessous.

Exemple de typologie de Catégories

Risque

Budget

Extrêmement Large (XL)

Large (L)

Élevé

Élevé

Supérieur à 10M€

Entre 3M€ et

10M€

Medium (M)

Medium

Entre 500K€ et 3M€

Petit (S)

Faible

Inférieur à 500K€

Exemple 11: Typologie de projet classifié par budget

L’inconvénient de ce type d’approche est que la taille ne détermine pas l’importance politique ou stratégique du projet. Si cela se trouve, un projet de

20k€ peut être stratégique pour le Business et sa réalisation peut nécessiter les meilleures ressources, quitte à les faire sortir d’un mégaprojet le temps de réaliser le petit projet à importance capitale pour le Business. Comité de pilotage pour un projet Large ou Extra Large Dans l’exemple ci-dessus, toute organisation concernée par la réussite de ses projets met en place un comité de pilotage (steering committee) lorsqu’il s’agit d’un projet de taille large ou extra large. Certaines organisations abandonnent trop souvent le Manager de Projet à son sort, ce qui favorise l’échec. Pour qu’un projet (et surtout un grand) connaisse le succès, l’appui d’un

comité est nécessaire. Afin d’obtenir des résultats positifs, il faut dresser et définir très tôt les points suivants : Les membres du comité de pilotage : Qui doit faire partie du comité ? Les rôles et responsabilités: Quels sont les rôles et responsabilités de chaque membre du comité et le rôle de l’équipe projet ? Il faut établir proprement une structure de gouvernance du projet. S’assurer que les rôles et responsabilités ainsi que la structure de gouvernance sont correctement assimilés par les membres du comité de pilotage et de l’équipe projet. On

ne veut pas d’un micro-management ni d’une implication trop passive du comité de pilotage, mais bien d’un support constant, même quand il s’agit d’implémenter des décisions impopulaires. On a ici besoin d’un comité qui discute en toute liberté et sans arrière-pensée, les bonnes comme les mauvaises nouvelles. Processus : Comment ce comité de pilotage devrait-il fonctionner ? (voir exemple ci-dessous) Management du projet : Quels méthodologie et processus doit-on mettre en œuvre pour réaliser le projet ? Exemple de processus pour Comité

de Pilotage (CP) pour un projet large (L) ou Extra Large (XL) Pilotage et Communication Quelle information sera Exigences du passée à business? l’équipe projet? De quelle Rapport information le hebdomadaire? comité a-t-il Débriefing en facebesoin pour faire à-face? proprement du Contenu? pilotage? Comment le Réunion régulière comité de avec les parties pilotage et le prenantes sponsor vont-il (stakeholders) clés? communiquer

entre eux et avec les parties prenantes (stakeholders)? Quelles informations doivent être communiquées vers les parties prenantes du Business et les clients externes? Réunion

Fréquence des réunions

Copie des rapports de réunion du comité de pilotage vers les parties prenantes?

Décision du CP? État du projet régulièrement? Échéanciers (schedule)?

Mensuelle, hebdomadaire? Quel jour? Mettre une série dans le calendrier de chaque personne et à

l’avance? Le Manager de Qui facilitera Projet? Le directeur les réunions? de programme? Le sponsor? Le client? En général, on ne Qui prendra trouve personne ici. les notes et fera Choisir quelqu’un que les comptesl’on veut former au rendus? management. La même personne Qui va qu’en haut. Le manager le Manager de Projet fichier log peut le faire mais on d’action et en l’imagine déjà faire le suivi? débordé par le projet. Prise de décision Quel sera le Vote? processus de

prise de décision? Qui peut participer à la prise de décision? Quels types de décisions peut prendre le CP? Quels types de décisions peuvent prendre les membres de l’équipe projet? Quels types de décisions

Consensus? Ordre d’en-haut? Quels membres du CP? Quelles parties prenantes? Le Manager de Projet? Activation du « Kill Switch »?

peut prendre le Manager de Projet? Escalade Comment les problèmes vontil être escaladés pour la résolution de l’équipe projet vers le comité de pilotage? Quels problèmes le Manager de Projet peut-il résoudre et quand est-il autorisé à le faire ? Quels

Seulement durant les réunions du CP? De façon hebdomadaire par le Manager de Projet? A chaque fois qu’il y a escalade par le Manager de Projet?

sont les problèmes dans lesquels le CP doit être impliqué? Résolution des conflits Comment les disputes et les conflits doiventils être résolus ?

Décision du sponsor? Consensus du CP? Décision individuelle?

Exemple 12: Processus de fonctionnement du Comité de Pilotage

Typologie de projet par l’effort Certaines compagnies déterminent la typologie de projet en fonction de l’effort à fournir en termes de jourshommes, comme suit :

Typologie de projet par l’Effort Catégories Effort (jour-personne Maintenance Inférieur à 50 Petit Entre 50 et 500 Moyen Entre 500 et 3000 Large Entre 3000 et 20 0 Extrêmement Supérieur à 20 00 Large Exemple 13: Typologie de projet classifié par l'effort

On rappelle pour les novices et pour ceux qui prétendent connaître la formule sur le calcul de l’effort.

A savoir qu’un effort égal à 60 peut signifier: 1. Qu’il faut 1 jour à 60 personnes pour réaliser le projet. 2. Qu’il faut 60 jours à 1 personne pour réaliser le projet. 3. Qu’il faut 15 jours à 4 personnes pour réaliser le projet. 4. Qu’il faut 5 jours à 12 personnes pour réaliser le projet. 5. Etc. (si vous ne comprenez toujours pas, peut être le management de projet n’est-il pas fait pour vous. Avez-vous déjà pensé à essayer le commercial ?)

« Neuf femmes ne pourront faire un enfant en un mois. » Proverbe chinois Dans ce cas, le Manager de Projet dose en fonction de l’effort la méthodologie à privilégier pour un projet ou un autre. Nous verrons dans la section management de projet qu’il ne faut jamais tomber dans le piège du boss qui insiste pour que vous réalisiez un projet en un minimum de temps. Cela revient à mettre le maximum de ressources sur votre projet, ce qui peut être un problème. Cependant, il convient de garder à l’esprit que s’il faut toujours neuf mois à une femme pour faire un enfant, Il est impossible pour neuf

femmes de mettre au monde un bébé en un mois. Il faut également tenir compte de la loi de Brooks selon laquelle ajouter des ressources sur un projet en retard accroit encore son ajournement.

Loi de Frederick Bro à un projet en retard s ce retard. En effet, le p au nouveau système négligeable que la prod en question ne peut co besoin de formation. D de de communications. Loi 1: Frederick Brooks sur les ressources

Typologie par heure et par revenu

Pour certaines entreprises, un projet à 1M€ constitue une routine, tandis que pour d’autres, il peut s’agir d’un mégaprojet. Nous avons déjà abordé le fait que chaque organisation devait définir la taille de ses projets en fonction de ses pratiques. Jolyon Hallows, dans son livre «The Project Management Office Toolkit », affirme qu’un projet qui compte le plus d’heures (effort) peut ne pas être celui qui détient le plus petit revenu. Il conseille alors la classification de la taille de projet soit par les revenus soit par le nombre d’heures (Exemple 14: Typologie de projet classifié par nombre d'heures et de revenus

Typologie de projet par nombre d’heures et de revenus Quel est le plus petit projet 1 entrepris ? Petite 2 Moyenne 3 Large 4 Quel est le plus grand projet 5 entrepris ? Exemple 14: Typologie de projet classifié par nombre d'heures et de revenus

Selon lui, il faut également fouiller dans les facteurs environnementaux de

l’organisation, et particulièrement dans la base de données qui contient l’historique des projets. Une fois ceci fait, entrez dans le tableau ci-dessus, dans la rangée n° 1, le plus petit nombre d’heures passées sur un projet (par exemple Heure Min= 100) réalisé par votre organisation. Ensuite, faites de même pour le revenu, et insérez dans le tableau, dans la rangée n° 1, le plus petit revenu que votre organisation ait reçu d’un projet (par exemple Revenu Min = 10k€). Ces valeurs peuvent cependant ne pas être issues du même projet. Maintenant, faites de même pour le plus grand nombre d’heures passées sur un projet (par exemple : Heure Max= 12.000), et le plus grand revenu jamais

généré par votre organisation (par exemple Revenu Max= 2M€). Enfin, pour construire votre abaque, vous devrez appliquer la formule suivante : Heure Petite = (Heure Max – Heure Min) /4 + Heure Min = 3075 Heure Moyenne = (Heure Max – Heure Min) /4 + Heure Petite = 6050 Heure Large = (Heure Max – Heure Min) /4 + Heure Moyenne = 9250 Il suffit alors de faire de revenus en arrondissant. construire votre abaque Typologie de projet

même pour les Vous venez de (Exemple 14: classifié par

nombre d'heures et de revenus Donc, si vous êtes amené à gérer un projet de 7000 heures qui produira 1.7M €, si l’on se réfère à l’abaque, votre projet est de classe moyenne en nombre d’heures et de classe large en termes de revenus. Encore une fois, la classification des projets, que ce soit par budget, par revenu ou par effort, revient à l’organisation, et la méthodologie à utiliser pour manager le projet doit se faire en fonction de la taille de celui-ci. Nous étudierons les méthodologies dans la prochaine section.

Le projet et la triple, voire la quadruple contrainte Tout le monde a certainement déjà entendu parler des triples contraintes comme illustration de l’interdépendance des variables d’un projet. Ces dernières varient d’une entreprise à l’autre : certaines organisations accordent davantage d’importance à l’équilibre entre les variables de coût, les ressources et le délai, tandis que d’autres s’intéressent plus à l’équilibre entre les variables de coût, le scope et le délai. Enfin, certaines entreprises s’attardent sur l’équilibre entre les variables de coût, le temps et la qualité.

Toujours est-il que le délai figurera inlassablement dans ces contraintes, car il est l’ennemi de tout projet, ainsi que les coûts, puisque l’argent est la racine de tous les maux, surtout quand il s’agit de projets.

Figure 7: Triple Contrainte

Mais quelles que soient les variables prises en compte dans la triple contrainte, l’idée (toujours la même) est la suivante : les modifications apportées

à l’une des variables se feront aux détriments des autres et auront obligatoirement des conséquences sur elles.

Scope du projet (c travail à effectuer po résultat, présentant spécifiées. (PMBoK® Scope : Somme de fournir sous forme de Définition 1: Scope ou Scope d'un projet

Modification du délai : Sur un projet donné, si on décide de réduire le délai de livraison du projet tout en maintenant le scope et la qualité convenus, alors il convient d’ajouter plus de ressources et donc par

conséquent, davantage de budget. Autrement, si l’on veut dépenser moins d’argent, ou en tout cas ne pas en dépenser plus, il faut alors accepter de réduire le scope et la qualité définis au préalable. Modification du budget : Si l’on veut réduire le coût d’un projet donné tout en maintenant le scope et la qualité convenus, il faut alors augmenter le délai de livraison du projet. Sinon, si on cherche à réduire les coûts tout en faisant preuve d’impatience et en conservant le même délai, voire en le réduisant, la solution se trouve dans la réduction des attentes sur le scope et la qualité

convenus. Modification du scope : Un changement de scope du projet entraine inéluctablement une modification du coût et des délais du projet. Redéfinir le scope revient toujours à modifier le coût et le délai. L’un des facteurs d’échec des projets est le changement de scope non contrôlé (scope creep). Le Manager de Projet doit instituer un processus de management intégré du changement de scope qui permettra de délimiter correctement les frontières du projet : la dépendance, ce qui ne figure pas dans le scope, les contraintes, les hypothèses. Il faut

promouvoir la culture du management du changement de scope. Nous aborderons dans la section 3 le management intégré du changement de scope.

Scope creep (Dérive de caractéristiques projet) sans tenir co coûts et les ressourc (PMBoK®) Définition 2: Scope Creep ou Dérive du scope

Gary R. Heerkens est l’auteur de plusieurs livres sur le management de projet. J’ai eu l’occasion de le croiser dans un workshop sur les outils, templates ettechniques lors du congrès

de PMI en Europe en 2010. Selon lui, la dimension de la triple contrainte n’est pas suffisante et il convient d’en ajouter une quatrième. Ainsi, on aurait : 1. Coûts : Le projet a-t-il respecté les coûts initiaux ? 2. Temps : Le projet a-t-il respecté le temps imparti à sa réalisation ? 3. Fonctionnalité : Le projet a-t-il livré toutes les fonctionnalités attendues ? 4. Qualité : Le projet ne souffre-t-il pas de défauts ou de défaillances particulières ?

Figure 8: Quadruple Contrainte

Il mentionne également qu’il existerait une zone d’échange où l’on troque souvent la qualité ou la fonctionnalité au détriment du temps et des coûts. Ainsi, sur un projet donné, plus on réduit les ressources (temps, coûts), plus on troque sur le scope (fonctionnalité, qualité). Un exemple classique est l’entreprise qui rogne sur les coûts des tests qu’elle organise partiellement, avec pour conséquence directe une absence de contrôle de la qualité des fonctionnalités. Certaines organisations se passent carrément de tests et livrent un projet de très mauvaise qualité. Selon vous, laquelle de ces contraintes Toyota

a bien pu troquer dans cette situation où le constructeur automobile japonais a dû rappeler plus de dix millions de véhicules dans le monde depuis l'automne 2010, dont la grande majorité aux Etats-Unis, pour cause de différents problèmes, essentiellement le blocage des pédales d'accélération en position enfoncée ou dans des tapis de sol ? En période de crise, les managers de projets se trouvent face à un budget plus serré, draconien, et à des deadlines plus rigoureuses, très strictes. Cela ne devrait pourtant pas être le cas, et surtout concernant la dérive du scope (scope creep). Sachez donc dire non lorsqu’on vous demande de livrer un projet

infaisable ni dans les délais ni dans les coûts impartis. On a déjà vu que troquer certaines fonctionnalités ou la qualité afin de réduire les coûts n’offre pas un produit, un résultat ou un service fini mais bien quelconque. Sachez partir, surtout si on vous demande de sacrifier la qualité, car il n’y a rien de plus honteux et de pire que de livrer un projet de piètre valeur. De plus, les personnes qui vous auront demandé de le faire risquent de vous reprocher ce manque de qualité par la suite, même si elles se trouvent à l’origine de la coupe du budget et de la réduction du délai de livraison.

Objectifs S.M.A.R.T. des projets L’énoncé des objectifs de projets est l’un des facteurs de réussite d’un projet. L’échec est en effet inévitable lorsque les buts ne sont pas clairs. Si vous ne savez pas où vous allez, vous risquez de vous retrouver ailleurs sans le savoir. Nous avons vu que les problèmes mal définis engendraient une infinité de solutions. Afin d’éliminer tout facteur de malentendu, et donc d’échec du projet, il est primordial de bien énoncer ses objectifs. Pour cela, la méthodologie SMART est généralement proposée. Les objectifs doivent donc être :

Spécifiques : Le projet doit tendre vers un objectif ciblé. Mesurables : On peut vérifier avec le client que le produit répond aux spécifications demandées telles que la taille, le poids, la puissance et la capacité. C’est un indicateur de succès du projet. Atteignables et ambitieux : Il est possible de réaliser l'ouvrage avec la technologie et les connaissances disponibles ou accessibles à ce jour, même s’il est urgent d'innover. Raisonnables et réalistes : L’entreprise n’a pas promis la Lune. Elle a la capacité de répondre à la demande et le changement demandé

est à sa portée même s'il s'agit d'un défi. Temps (inscrit dans les temps) : La date de remise du produit, et par extension le délai, sont respectés. Il est préférable, voire conseillé, de formuler les objectifs du projet par un verbe d’action, car l’idée est d’entreprendre une série d’actions par la suite pour atteindre les objectifs du projet.

Enoncé d’objectifs de projet : Enviro (ETC) : Les objectifs de ce projet se dé 1. Implémenter un Environn simple d’usage, fiable et travail en équipe, des works téléconférences, des présentations o

crise (War Room) ou les réunions no 2. Utiliser dans cet ETC les no communication (vidéoconférences e (les outils de visualisation, des tabl ou whiteboard, chat, etc.) afin que physiquement se rencontrer da constamment en mesure de partag leurs ordinateurs portables vers u virtuellement, afin d’inciter à la dis décisions ensemble plus rapidement. 3. Mettre en place un processus pou discipline puissent travailler ensem physiquement, soit virtuellement, temporelles, culturelles et organisa renforcés par les technologies mises 4. Mettre en place un processus de c pas intrinsèquement une question de de personnes. Ainsi, il faut créer le

les conditions appropriées pour un compte des tiers de Napoléon (voir c 5. Faire des économies sur les dépens n’aura plus à se déplacer. Il suffit en entrer en contact avec ses collègues Exemple 15: Enoncé des objectifs d'un projet en suivant la méthodologie SMART

Dans la réalité, j’ai vu les objectifs de ce projet atteints un par un comme ils ont été annoncés ci-dessus. Ils étaient spécifiques et on pouvait les mesurer tout au long du projet, ainsi qu’après. De même, ils avaient un caractère ambitieux mais atteignable à la fois, car ils demandaient l’utilisation de la nouvelle technologie en vogue. En plus, ces objectifs étaient réalistes et surtout

raisonnables, car on peut toujours ajouter un peu de fantaisie déraisonnable dans ce genre de projet. Ce projet a été livré en 6 mois, et son utilisation ainsi que son exploitation sont devenues de plus en plus populaires, ne faisant que croître et du même coup, générant beaucoup de revenus. De plus, le Business a également vu les coûts de déplacement réduits, car les équipes en remote se déplaçaient moins souvent et la productivité de l’équipe a été optimisée en les faisant travailler ensemble et en brisant l’approche « silo » où chaque membre de l’équipe participe de façon isolée à partir de son bureau ou de chez lui. Le ROI est très positif pour le Business et je ne peux

que recommander la mise en place de cet ETC chez les entreprises qui veulent encourager le télétravail et défendre la planète en réduisant la congestion générée par les trafics routiers dus aux allers-retours que nécessite le travail. Et comme parfois, un dessin vaut mieux que mille mots, voici ce qui a été implémenté (voir Figure 9: Projet ETC). "Si tu ne sais pas où tu vas, tu risques de mettre longtemps à y arriver" Proverbe Touareg

Figure 9: Projet ETC

L’un des exemples d’utilisation de cet ETC est de servir à toute équipe de projet de salle de crise (War Room) pour toute discussion relative au

management des projets. L’ETC est devenu la pièce dans laquelle il est possible de débattre des problèmes, des moyens de résoudre les crises relatives au projet, ou de fréquentes interprétations erronées. On fait un brainstorming par exemple sur des solutions à adopter, on discute du planning, des risques avec image à l’appui, car les informations visuelles pertinentes peuvent être affichées par le biais d’outils de visualisation installés dans la salle de crise. Par exemple, les images des personnes présentes aussi bien dans la salle qu’en télétravail sont diffusées sur l’écran 1. Ceux qui sont en télétravail peuvent alors être vus et voir les autres personnes présentes dans

l’ETC avec une webcam et également partager leurs écrans d’ordinateur sur tout écran présent dans l’ETC. Ensuite, l’architecte est capable de projeter l’écran de son ordinateur sur l’écran 2, le développeur qui est en télétravail, sur l’écran 3 et le Manager de Projet, sur le whiteboard (tableau blanc) sur lequel il peut également procéder à des modifications ou écrire en direct le compte-rendu de la réunion. Il lui est ensuite possible de sauvegarder ce qui a été écrit sur le whiteboard (et que tous auront vu et accepté) sur son propre ordinateur, et d’envoyer le rapport à qui il le souhaite. L’ETC est devenu un endroit reconnu pour la communication entre co-équipiers, puisque c’est le

moyen le plus simple de s’entretenir physiquement ou virtuellement avec toutes les personnes impliquées dans le projet. De même, il s’est transformé en un lieu où les meilleures décisions peuvent être prises très rapidement, sans devoir attendre la prochaine rencontre en face-à-face avec l’équipe ou s’adonner à de longs échanges d’emails. Par exemple, quand une équipe se retrouve au même endroit, les processus de décision se prennent rapidement.

Le tiers de Napoléon concernant la employés Selon Gary Starke et D dans leur ouvrage « Ch toute population, il existe au changement :

Le 1er groupe (10% - 30%) soutie De manière générale, il sera prêt à te Le 2ème groupe (40% - 80%) accep voir quelle idée l’emporte avant de personnes soumises à l’autorité. Le 3ème groupe (10% - 30%) ne prises et il résistera activement ou changement. Loi 2: le Tiers de Napoléon sur la résistance à tout changement

Un projet possède des stakeholders (parties prenantes) Le succès de tout projet repose entièrement sur le degré d’implication et la force d’engagement des personnes qui sont amenées à y contribuer, mais aussi de celles qui sont en mode « silence » bien qu’également intéressées par les résultats. Ces

personnes, qui peuvent avoir une influence faste ou néfaste sur l’issue d’un projet, sont appelées les stakeholders. Elles peuvent être internes ou externes à la compagnie et leur influence est considérable en début de projet, surtout lors de la définition des objectifs et de l’obtention du budget. Il faut donc une approche rigoureuse dans le management de ces stakeholders dont le manque de support est l’un des facteurs d’échec des projets.

Stakeholders (par organisations telles qu entreprises réalisatrice dans le projet ou dont les intérêts peuv ou négative par l’exécution ou l’achève peuvent également influencer le projet e

Définition 3: Stakeholders ou Parties Prenantes

Dans un environnement de projet de plus en plus complexe et de plus en plus multiculturel, une bonne compréhension des stakeholders est cruciale. Par exemple, un très bon Manager de Projet (vous qui est êtes en train de me lire) devrait toujours avoir une idée précise des stakeholders hostiles au projet (ceux qui auront un impact négatif sur lui, en retenant des informations ou en refusant de le supporter), de ses alliés (ceux qui défendront bec et ongles le projet et qui lui seront bénéfiques), des décideurs (ceux qui ont un grand pouvoir d’influence sur la prise de décision le concernant) ou des détenteurs

d’informations les plus pertinentes contribuant à la réussite du projet. Un bon Manager de Projet doit avoir analysé au préalable les stakeholders et déterminé lesquels sont faibles ou très occupés, lesquels tendent à abdiquer leurs rôles et à toujours laisser l’équipe de projet prendre les décisions. Le Manager de Projet doit également déterminer qui est responsable de la décision finale et qui doit supporter ou accorder les finances ou les ressources. Enfin, le Manager de Projet doit savoir déterminer lequel des stakeholders peut perdre gros si le projet n’est pas signé ou encore, lequel a tout intérêt à prévenir ou à empêcher la décision d’entreprendre le projet d’être prise.

Afin d’atteindre ce degré de compréhension des stakeholders, il faut commencer par les identifier. Ensuite, il convient d’établir le contact avec eux efficacement, afin de se constituer un réseau de relations sur le projet et du même coup, une crédibilité. En effet, sans vouloir vous mettre la pression, il est indispensable de faire bonne impression lors du premier contact et de construire sa crédibilité en inspirant la confiance et le respect aux stakeholders. J’ai tellement vu de managers de projet se faire griller sur ce point…

Stakeholders par catégo Individus

Groupes

Extern société

Président, VP Sponsors du projet Manager du projet Équipe projets Utilisateurs Clients finaux Managers

Comité de direction Comité de pilotage (Steering Committee) Les équipes Le support Utilisateurs (Clients) Etc

Clie Les actionn Les gouver Les Con Autr organi norma Fou Etc

Propriétaires du projet Etc. Exemple 16: Stakeholders par catégorie

Si le courant passe et qu’il y a du respect et de la confiance mutuelle, c’est

un point positif pour tout le monde et surtout pour le projet. Car dans ce cas, on a tendance à être plus généreux, à mieux écouter, à ne voir que le bon côté et à se surpasser. Dans le cas contraire, si la première impression est mauvaise et que le courant passe mal, on pourrait être déçu et passer à côté de ce qu’on est en mesure d’offrir de meilleur, tout en ne se concentrant que sur les points de discorde. Mais rien n’est perdu, et la situation peut toujours être retournée, même si cela devient difficile pour le management du projet. Soit, il ne faut surtout pas vous laisser impressionner puisque de toute façon, les stakeholders vont jouer les gentils, les polis, tant qu’on ne leur demandera rien. Mais ils

vous botteront en touche dès que vous solliciterez leur engagement. Vous devez donc susciter leur adhésion au projet et tenir vos promesses.

Identifier les stakehold processus qui consiste à organisations touchées p informations pertinentes participation et leur projet. (PMBoK®) Définition 4: Identifier les Stakeholders

Pour identifier les stakeholders (parties prenantes), il faut tout d’abord savoir si elles sont des entités internes ou externes à l’organisation et qui possèdent les caractéristiques

suivantes : Sponsorise le projet : La personne qui supporte financièrement le projet. Son influence est donc grande car sans financement, il n’y a pas de projet. Le sponsor peut être le comité de direction ou l’un de ses membres, une institution publique ou privée, etc. Par exemple, l’Union Européenne finance les 3,4 milliards d’euros du projet Galileo (GPS Européen) qui sera exploité par le privé une fois opérationnel. Ont un intérêt ou un gain particulier dans la complétion du projet : Un projet crée un service, un résultat, ou un produit unique pour

une cible particulière, et c’est cette cible qui trouve un gain ou un intérêt dans l’aboutissement du projet. Peuvent avoir une influence positive ou négative sur la complétion du projet : Certaines personnes veulent peut-être la mort du projet et ont une grande influence sur ses mécanismes de lancement et d’arrêt. Il faut déterminer qui peut apporter son support ou qui va devenir un obstacle à la réalisation des activités du projet. Projet ITER à Cadarache: stakeholders sur un mégaprojet Ce projet est destiné à vérifier la « faisabilité scientifique et technique

de la fusion nucléaire comme nouvelle source d’énergie ». Sponsor : Au départ, son coût était chiffré à 4,6 milliards d'euros pour les dix ans de construction, dont 45 % revenaient à la charge de l'Europe et 9 % à celle de chacun des six autres partenaires (Chine, Corée du Sud, États-Unis, Inde, Japon et Russie). Il faut ajouter à cela 4,8 milliards d'euros pour les vingt ans d'exploitation. Les pays membres du projet : la Russie, la Chine, la Corée du Sud, les États-Unis, le Japon, l'Union Européenne, l'Inde (à hauteur de 10%), la Suisse (en raison de son association au programme européen de recherche) et le Brésil, qui a

également posé sa candidature afin de rejoindre le projet. En 2007, le Kazakhstan a fait savoir qu'il désirait être membre à part entière du programme, ce qui peut se réaliser sous réserve de l'accord des gouvernements des autres partenaires. Management de l’ITER: Réalisé par un ensemble d'instances où se réunissent les différents membres. La principale instance est le Conseil ITER, situé à Moscou, en Russie. Il est composé de huit membres : deux européens, deux russes, deux japonais et deux américains. Le conseil de l’ITER : Assisté d'un comité technique (appelé le Technical advisory committee ou TAC) et d'un comité de management

(le Management advisory committee ou MAC). Exemple 17: Identification de Stakeholders sur un projet

Les attentes des stakeholders et ce qu’on attend d’eux en relation avec le projet « Il n’y a pas de recette pour le succès, mais il existe une recette pour l’échec : essayer de faire plaisir à tout le monde » Man Ray Quand on a identifié les stakeholders, l’étape suivante est de déterminer les attentes de chacun d’entre eux : qu’attendent-ils du projet ? Qu’est ce que le projet attend d’eux ? Et quel est l’impact du projet sur eux ? Vous trouverez autant de besoins et d’attentes

qu’il y a de stakeholders. En effet, chacune des parties prenantes tient à ce que ses propres intérêts soient assouvis par le projet. Or, il faut manier l’art du management de projet pour combler le fossé entre les attentes des stakeholders et ce que le projet peut leur donner. De même, faire cohabiter sur le même projet tous ces égos nécessite beaucoup de diplomatie, et il faut savoir construire un pont entre les intérêts de chacun, qui peuvent parfois être conflictuels. Ainsi, le management de projet est aussi l’application des outils et techniques appropriés pour satisfaire les exigences des stakeholders. Projet Nabucco: attente

(conflictuelle) des stakeholders sur un projet Nabucco est un projet de construction de pipeline qui permet à l’Union Européenne (UE) d’avoir du gaz en provenance de l’Asie Centrale afin de ne pas dépendre exclusivement de la Russie. Or, dans le projet concurrent (South Stream), initié par les Russes pour capter la même ressource gazière, on retrouve l’Italie qui est un état membre de l’Union Européenne (UE) et qui fait donc partie du projet Nabucco. Ainsi, on peut retrouver le même stakeholder sur deux projets concurrents, mais ses attentes ne seront pas les mêmes selon le projet et de même, ce qu’attendent les deux projets du

stakeholder différent.

peut

être

égal

ou

Exemple 18: Attente conflictuelle des stakeholders sur un projet

Dans tout projet, en parallèle avec l’écriture de la charte de projet et bien avant de rédiger le plan de management du projet ou de définition de scope, il faut faire un exercice de mapping des attentes des stakeholders sur le projet et ce que ce dernier attend des stakeholders, et de son impact sur eux. On peut par exemple aboutir à un résultat comme indiqué ci-dessous.

Analyse et mapping des att inversement, mapping de l’ Le projet consiste à organiser et diri

Manager de Projet, en l’occurrence l’or livrer la cérémonie de mariage du sièc cérémonie s’étend sur un an afin d’av lieu et la date et de planifier correctem les époux ont demandé que les réjouiss augmente la tâche du manager du proj toute la préparation. Avant de définir retroplanning à partir de la date pr Manager de Projet doit au préalable prenantes. P.S: Toute ressemblance avec des perso Ce projet est de la fiction et sert juste d’analyse des attentes des stakeholders Exemple 19: Analyse et mapping des attentes des stakeholders du projet

Attente du

Partie prenante

Nicolas

Rôle

Le futur époux

Stakeholder d projet

La future épouse ne change pas d’avis. Cérémonie montrant qu’il est le roi du monde. La belle-mèr ne gâche pas la soirée. Les excompagnons d la future marié ne viennent pa en nombre à la cérémonie.

Bien collecte les cadeaux (cash, verseme sur compte offshore, etc.) Rédiger le régime matrimonial (contrat de mariage). Publication des bancs dans tous les journa et télévisions d monde. Cérémonie parfaite. Choix des prestataires (animation

Carla

La future épouse

musicale, décoration florale, traiteur voiture). La belle-mèr ne gâche pas la soirée. Que les excompagnons d la future marié ne viennent pa en nombre à la cérémonie. Préparer les faire-part. Réserver les voyages de noces. Réfléchir au vœux.

Jacques

Maman

Silvio

Père du marié

Mère du marié

Père de la mariée

Pouvoir exposer ses peintures sur le lieu de la cérémonie. Des têtes de veaux et de la Corona.

S’assurer qu y a un nombre égal d’invités d la part des deu familles. Etablir un planning et un budget précis pour

Marisa

François

Mère de la mariée

Manager du projet (organisateur)

l’événement. Présence de mannequins. Une visite médicale prénuptiale, y compris une analyse psychique du futur gendre.

Obtenir un budget illimité une totale indépendance pour organiser cérémonie. Prompte coopération et envie de

Dominique

Le témoin du marié

collaboration d deux familles pour préparer cérémonie. Pouvoir joue son rôle sans aucune influence. « Connaitre commande » pour éviter toutes mauvais surprises pour l’enterrement d vie de garçon. Une liste des amis (s’il en existe) à invite pour l’enterrement d

Ségolène

Le témoin de la mariée

vie de garçon. Un mariage juste et participatif. Définition de périmètres de son rôle. Accepter qu’elle ne contrôle pas la situation au diable la peur d ridicule. Une indicatio sur ce que n’aime pas la mariée pour l’enterrement d vie de jeune fil pour éviter une

expérience déplaisante.

Les invités

Présents au mariage

Hébergemen Transport. Garderies.

Exemple 20: Analyse et mapping des attentes des stakeholders du projet (suite)

À noter que dans cet exemple (Exemple 19: Analyse et mapping des attentes des stakeholders du projet), le projet attend du Manager de Projet une prise en compte de la différence de culture entre

les deux familles lors de la cérémonie. Cela signifie que, lors de la définition du scope et du plan de management du projet, le Manager de Projet doit tenir compte des traditions des deux cultures pour organiser la cérémonie, et vérifier si le placement d’interprètes à chaque table n’est pas nécessaire, ou si la cérémonie ne devrait pas se tenir dans les deux langues concernées. Technique d’analyse des stakeholders Afin de mener à bien l’exercice cidessus, à savoir l’identification et l’analyse qualitative des attentes de chacun des stakeholders et de ce que le projet attend d’eux, on peut s’entretenir en face-à-face avec chacune des parties prenantes. Cela permet de déterminer

leurs attentes et d’exprimer ce que le projet attend d’eux. Lors de cet entretien, il faut être en possession de la charte du projet. À la suite de cette réunion, il faut avoir obtenu une signature de leur engagement pour la réussite du projet. Je le rappelle encore, l’un des facteurs d’échec du projet est l’insuffisance, voire l’absence de support des stakeholders. Sur un projet international, il arrive que vous voyagiez partout dans le monde. Oui, vous devrez donc prendre des avions, changer votre routine de métro-boulotdodo, aller à l’aéroport, subir les trajets, etc. Mais c’est un mal nécessaire pour le bien du projet. Quand les choses tournent mal et que certaines parties

prenantes commencent à se désengager du projet, l’astuce est de sortir le petit papier sur lequel elles ont signé leur engagement. Ceci peut être un contrat, un teaming agreement, un accord de consortium, ou ce qu’on veut, mais il faut un papier sur lequel le stakeholder a pris connaissance du projet, a compris le contenu, et s’est engagé à livrer sa part et à supporter le projet jusqu’au bout.

Technique d’analyse des stakeholders par u 1. Mesurer la compréhension projet par les stakeholder l’importance du projet ? Ont-ils compris le

de s’engager dans le projet ?

On peut poser les questions suivantes par exe Quelle est son impression sur le pro mesure-t-il l’importance de l’effort qu’ Cet effort est-il vraiment nécessaire? quant au fait de fournir cet effort? Quelle est sa compréhension de vraiment clair? Est-ce SMART? Pourq Cela vaut-il le coup pour le stakeho argent sur ces objectifs ? Pourquoi? Po

Qui a les besoins les plus critiqu absolument se faire? Quels sont les challenges ou obs impact important sur le résultat de stakeholder de façon générale?

2. Il faut s’interroger sur l’implication perso projet.

Quel est l’impact du résultat du pro

soit pour des bénéfices ou des pertes? Quels bénéfices tirerez-vous directe projet? Comment les changements potentie sur vous ou votre rôle dans le projet? Quel degré de support les lea offriraient-ils à ce projet? Adoptent-ils les comportements appropriés pour sup Êtes-vous prêt et souhaitez-vous su ses livrables? Si on vous dem personnellement dans la planification o seriez-vous d’accord ? 3. Faites un rapport sur le contenu de l’entre Exemple 21: Technique d'analyse des Stakeholders

Un projet a des hauts et des bas, des temps forts et des temps faibles Enfin, avant de décortiquer la définition d’un projet à laquelle on se référera tout au long de l’ouvrage, il conviendrait de mentionner une dernière caractéristique des projets : comme dans la vie, les projets traversent des hauts où tout paraît beau et des bas où plus rien ne va, comme l’illustre le graphique imaginé par Els van Mourik et Danny Hearty dans « Knowing me Knowing you: an intellectual training resource pack, Léargas ».

Figure 10: cycle de vie « haut » et « bas » d'un projet de Els van Mourik et Danny Hearty

Un projet est une aventure humaine vécue par le Manager de Projet, l’équipe de projet et les stakeholders. Des liens se créent entre ces parties : de l’affinité, de l’animosité, certains vont devenir des alliés, d’autres des résistants au projet, etc. Chaque expérience vécue sur un projet est unique car, même si on recommence le même projet avec les mêmes personnes au même endroit, tout sera réalisé différemment. Comme lors de toute aventure, chacun sent défiler toute une palette d’états : de la joie à la colère, en passant par la frustration et le stress et même, par la paranoïa. À certains

moments, des membres du projet ou des stakeholders n’y croiront plus, alors que d’autres seront encore remplis d’optimisme. Faire aboutir un projet revient à gagner la guerre que l’on mène dans les tranchées, en tirant le maximum de ses ressources, où on livre différentes batailles contre le temps, le budget, la qualité, le scope, les problèmes prévus comme imprévus, tout en essayant de maitriser les différents facteurs environnementaux tels que la culture, la politique, les nouvelles technologies, les intérêts parfois divergeant et conflictuels des stakeholders, la méthodologie de management de projet etc. C’est une affaire de stratégie, de tactique, de

calcul, et parfois de survie du projet. Au départ, les sceptiques se montreront résistants au projet, n’y croiront même pas. Mais au fur et à mesure de leur collaboration active, ils finiront par y adhérer. Dans le cas contraire, il sera nécessaire de les remplacer. Ceux qui ont l’habitude de manager des projets savent qu’on n’attend pas Godot sur un projet, il s’y passe toujours quelque chose. Parfois, tout se déroule bien tandis qu’à d’autres moments, tout se passe mal et le Manager de Projet se sent abandonné(e) et tenu(e) injustement responsable de la situation, même si elle est due à des facteurs que l’on ne contrôle pas: une

énième escalade du client, un conflit ouvert entre stakeholders (intérêts conflictuels), la démission d’une ou plusieurs ressource(s), une crise financière (par exemple : Les grands chantiers de Dubaï retardés ou annulés à cause de la crise), un accident (une plate-forme pétrolière de BP qui coule dans le golfe du Mexique suite à une explosion, provoquant la pire marée noire jamais survenue aux Etats-Unis), une catastrophe naturelle (le Newmont Nevada Energy Investment était prêt à lancer son projet à 533 millions de US Dollar pour créer une centrale à charbon dans le désert du Nevada, mais l’ouragan Katrina s’est invité sur la liste des risques, et toutes les ressources

humaines et matérielles ont été réquisitionnées pour réparer les dégâts). Quand on prend plaisir à réaliser un projet, le temps passe vite. Mais si c’est le sentiment contraire qui nous anime, on commence à douter, surtout quand les résultats tardent à se montrer. À ce moment-là, on peut toucher les heures sombres du projet car tout le monde est atteint par l’incertitude. Depuis l’antiquité, la distance entre le Capitole et la roche Tarpéienne reste toujours courte. De l’échec à la réussite, il n’y a souvent qu’un pas, mais un pas qui coûte énormément d’effort et de conviction. « Si le monde explose, la dernière voix audible sera celle d’un expert disant que la chose est impossible. »

Peter Ustinov Dans les moments de « bas », lorsqu’on a l’impression que le projet touche le fond, le Manager de Projet est, pour une raison encore inconnue, souvent désigné comme le responsable de la situation. Beaucoup de managers de projets n’en pouvant plus de leur travail ont laissé le navire sans capitaine, devenus incapables de contrôler la situation. Or, je le rappelle, l’un des facteurs d’échec du projet est le manque de support des stakeholders. Et dans ces moments de crise où le moral est au plus bas, le Manager de Projet peut se sentir triste et seul. Certains managers de projet ont alors

tendance à vouloir démissionner, ce qui n’est pas une attitude responsable. Il faut en effet puiser dans ses réserves, chercher ce petit effort « extra », pour au moins déléguer proprement la responsabilité à un nouveau Manager de Projet. Ceci dit, il convient de laisser le temps au nouveau capitaine du navire de prendre ses aises avant de repartir de plus belle, sauf bien sûr, si on vous demande de faire votre valise avec effet immédiat ou si l’équipage a conspiré pour vous jeter par-dessus bord en pleine mer. Un bon Manager de Projet n’abandonne pas, mais au contraire persévère, quitte à changer d’approche, de stratégie, voire d’équipe. Il continue et affronte les obstacles, l’un après

l’autre. Dans ces moments, se rendre dans des cercles de managers de projets (comme cité dans le chapitre sur le PMI®) aide à relativiser. Cela permet en effet de demander des conseils à nos pairs, dont beaucoup sont prêts à offrir leur soutient, aussi étonnant que cela puisse être. Si vous abandonnez au premier obstacle, pensez à exercer un autre métier car tout projet a ses montagnes à gravir, qui d’ailleurs nous rendent plus humbles et nous renvoient souvent à notre propre condition. Vous voulez une technique pour positiver l’équipe de projet pendant les réunions où l’on traite de ses problèmes ? Commencez par parler de ce qui a fonctionné, de ce qu’on a fait

correctement : cela ouvre les réunions sur du positif. Il n’y a rien de plus beau que la sensation d’avoir franchi des murs immenses et de récolter les fruits des efforts intenses fournis pour livrer le projet à temps. Il m’est arrivé plusieurs fois de passer des nuits entières avec l’équipe projet à vérifier les livrables, à faire en sorte qu’ils soient parfaits et professionnels avant de les envoyer. Je ne comprends pas ceux qui rendent des torchons et en sont fiers. On ne fait pas aux autres ce qu’on n’aimerait pas que l’on nous fasse, à savoir remettre une copie de piètre qualité. « Il n'y a point d'expérience qui élève mieux un homme

que la découverte d'un plaisir supérieur, qu'il aurait toujours ignoré s'il n'avait point pris d'abord un peu de peine. » Emile Chartier dit Alain Mais les mauvais moments finissent toujours par passer. En fortifiant nos positions ici et là dans les tranchées, en persévérant et en travaillant dur, les premiers résultats visibles finiront toujours par arriver. Nous verrons plus tard dans la section 4 comment on contrôle un projet. Car avec un bon management, on peut toujours atteindre des sommets. C’est dans la tempête que l’on juge réellement et qu’on peut répondre à cette question : est ce que le Manager de Projet tient-il vraiment la

barre dans la tornade? L’envie démesurée que doit avoir le Manager de Projet peut lui fabriquer les réussites et les victoires. De l’échec à la réussite, il n’y a souvent qu’un pas, mais un pas qui coûte énormément d’effort et de conviction. Ainsi, des « bas » on peut remonter dans les « hauts » de nouveau avec ce petit pas pour soi, qui est un grand pas pour le projet. Ces moments surviennent lorsqu’ on a l’impression que tout est sous contrôle, que les risques sont maîtrisés, que les problèmes ont des solutions et que le plan se déroule comme attendu, quand on commence à voir le bout du tunnel avec un morceau de résultat positif. Cette sensation est proportionnelle à

l’excitation, et sur un projet, ce sentiment survient souvent, comme par exemple lorsque l’on rend une copie conforme, un livrable qui dépasse toute attente, etc. Ce que nous ressentons est l’excitation d’un travail accompli et, plus la tâche a été ardue, plus cette impression est importante. La liberté c’est la consécration, on se sent léger et libre après une victoire. Il y a toujours une dynamique présente lors du démarrage d’un projet, que le Manager de Projet devrait chercher à capitaliser pour en tirer profit. Il faut savoir qu’à partir du début officiel du projet, le nombre de personnes impliquées dans le projet va croître de

façon significative, ainsi que les échanges d’informations, que ce soit sous forme d’emails ou de réunions physiques ou virtuelles par des conférences téléphoniques ou des vidéoconférences. Dans ces conditions, il peut vite devenir difficile d’avancer, de faire des progrès pour le PM qui risque de perdre rapidement son enthousiasme à l’idée de travailler sur quelque chose de nouveau. Sur un projet, il faut être capable de se préparer physiquement à l’effort avec plaisir car mener la tâche est surtout physique et ensuite seulement, mentale. Un projet mobilise donc à la fois les énergies et les esprits.

Il y a aussi un temps pour célébrer, qui ne survient pas forcement à la fin du projet, mais par exemple à chaque terme de milestone ou de livraison de livrables importants. Les équipes tendent à oublier de fêter les victoires. Pourtant, célébrer, c’est s’arrêter un moment, regarder le chemin parcouru et le partager avec les autres. C’est l’occasion d’honorer la bonne collaboration ou de la renforcer, mais aussi de faire le deuil du projet. Ce sera aussi la transition entre le projet qui vient de se finir et l’autre qui commence. Le vide laissé par un projet que l’on vient de terminer peut être déstabilisant car on passe du jour au lendemain d’un effort intense à une vie « normale. »

Certaines personnes ont du mal à oublier le projet, victimes des retombées d’adrénaline qui laissent un vide immense, celui qu’occupait le projet. Chaque Manager de Projet devrait apprendre à faire le deuil de son projet et également à apprécier ce moment de répit entre deux projets.

Définition d’un projet Tout au long de cet ouvrage, nous allons nous référer à la définition du projet fournie par le PMBoK® et qui s’énonce comme suit :

Projet : un effort tem créer un produit, un Un projet a un d (PMBoK®) Définition 5: Projet

Un projet crée un produit, un service ou un résultat unique

L’objectif d’un projet est toujours de créer un produit, un service ou un résultat unique. Le résultat unique créé par un projet peut être la mise en place d’une solution afin de résoudre un problème identifié pour lequel le projet a été créé. Le résultat est unique car il ne résout que le problème en question. Par exemple, le projet d’écrire un livre offre un résultat unique : l’ouvrage. Même si le même auteur réécrit l’œuvre, le résultat sera différent puisque l’expérience vécue par l’écrivain est unique lorsqu’il rédige la première édition. Top Kill – British Petrolium (BP): un projet qui crée un résultat

unique L’objectif de projet est de colmater provisoirement la fuite des puits de pétrole à l'aide d'une boue très épaisse. Cette solution a été imaginée pour résoudre le problème causé par la fuite d’un puits de pétrole qui a généré une marée noire et un désastre écologique sans précédent dans le golfe du Mexique. Exemple 22: Projet qui crée un résultat unique

Un projet qui crée un service peut être par exemple la construction d’un site de rencontre pour VIP, qui consisterait en la mise en relation de personnes appartenant à une classe sociale privilégiée. Dans ce cas, le projet crée un service unique et même si

plusieurs entreprises mettent en place le même type de service, il reste toujours unique car chaque compagnie aura sa spécificité dans la façon de réaliser le projet. Même si on procède à un copiercoller, il y aura toujours une différence puisque les créateurs du projet, l’environnement, le chemin parcouru durant le projet restent uniques. ROC – Air France : un projet qui crée un service unique Le Rappel Opérationnel Clients (ROC) d’Air France est un dispositif très réactif, au service des clients et qui offre un lien direct et permanent avec le Centre de Contrôle des Opérations aériennes de la compagnie. Ainsi, en

cas d’imprévu sur un vol, la compagnie avertit personnellement et le plus tôt possible les passagers. Exemple 23: un projet qui crée un service unique

Pour ceux que le mot « unique » incommode, il faut savoir que cela signifie simplement que la réalisation du projet est une expérience unique. En effet, on entreprend un ensemble unique d’activités et si le projet est à recommencer, il ne se réalisera peut-être plus avec les mêmes ressources, les mêmes environnements. De par leur nature, les projets sont des évènements qui ne se déroulent qu’une seule fois. Sinon, on aurait affaire à une routine, et donc à une opération.

On ne sait jamais ce qu’on peut obtenir d’un projet. En tout cas, l’application d’une bonne méthodologie de management de projet est l’un des facteurs capables d’augmenter les chances de réussite d’un projet. Bien que des éléments répétitifs se rencontrent dans certains livrables, l’ensemble des activités menées a un caractère unique. L’objectif du projet est singulier et ne sera réalisé qu’une seule fois à une certaine époque donnée.

Ainsi, chaque projet est unique et crée un service, un produit ou un résultat unique. Par exemple, si l’on passe ses vacances toujours au même endroit, toujours à la même période et toujours avec le même budget, chaque édition est unique car spécifique, et elle aura toujours une différence avec les autres. Le produit, le service, ou le résultat est unique car il est différent des autres produits, services ou résultats, même si le projet est une deuxième expérience. Passe Navigo – RATP : un projet qui crée un produit unique Le passe Navigo est le système de carte à puce sans contact qui utilise la technologie de radio-identification, plus

souvent désignée par le sigle RFID. Il contient les titres de transport utilisables en Île-de-France pour l'accès aux réseaux de transports dans cette zone. Exemple 24: Un projet qui crée un produit unique

C’est un peu comme redoubler sa classe : on peut apprendre la même chose, mais la façon dont les cours vont être dispensés sera différente. Le projet se déroule dans un lieu et un contexte spécifiques. Refaire le même projet est possible, mais ni le contexte ni le lieu ne seront identiques, on trouvera toujours des spécificités. Le projet fait appel à diverses compétences et implique souvent plusieurs acteurs.

Recommencer le même projet avec les mêmes compétences et les mêmes acteurs et en suivant le même chemin parcouru est impossible. Chaque étape vécue aura sa dissemblance, ce qui fera que le projet est unique. Ainsi, on peut conclure que chaque projet a ses propres spécificités et caractères qui tendent à le rendre unique.

Un projet est un effort temporaire Un projet sera toujours un effort temporaire car il consiste à monter intentionnellement une série d’activités pour accomplir un objectif précis dans un délai défini : résolution d’un

problème, besoin d’innovation, opportunité stratégique du business, demande du marché ou d’un client, obligation légale, etc. Ensuite, une fois l’objectif atteint, le projet est clôturé et on libère les équipes pour se focaliser sur un nouvel objectif. Les efforts consentis sont temporaires et ne durent que pendant la réalisation du projet : du début à sa fin. Et temporaire ne signifie pas nécessairement une brève durée de projet. On dit aussi que les choses les plus temporaires sont les plus permanentes, à savoir que le processus tend à s’éterniser et dans ce cas, l’on aboutit à un long projet ou une opération. Le projet de créer la Burj Dubaï a mis 5

ans par exemple, mais rares sont les projets qui dépassent 24 mois dans une entreprise. Un projet établit toujours un calendrier réaliste, il comportera toujours un début et une fin et la durée entre son démarrage et son aboutissement peut varier de quelques semaines, à quelques mois ou quelques années. En revanche, l’impact du projet est souvent plus long que sa durée de réalisation. Et le résultat unique de ces projets peut être durable. L’effort concédé pour mener à bien le projet est donc temporaire et ne dure que le temps du projet, mais l’impact du projet peut être durable.

Un projet n’est pas une

opération Les projets sont totalement différents des opérations de routine. Organiser le travail en projet prend sens dans la situation où le scope, le temps pour réaliser le projet et le coût sont des livrables clés et nécessitent des ressources aussi bien humaines que matérielles pour garantir la réussite du résultat. On a vu que ceci demande un travail unique et qu’un projet est un effort temporaire. Une opération de routine est menée quand un résultat bien défini est amené à être répété à plusieurs reprises. Effectuer chaque soir la sauvegarde de données d’un système d’information, par exemple, est une

opération de routine. Le résultat demande que les ressources coopèrent de façon régulière et accomplissent des activités répétitives.

Figure 11 : Projet vs Opération

Ces opérations de routine peuvent se poursuivre sans une fin déterminée. Cela ne veut pas dire que ces opérations sont simples, elles peuvent être très sophistiquées. L’impression d’un journal au quotidien est une opération de routine au processus très sophistiqué. Plus ce processus est optimisé, mieux on minimise la chance d’échouer, et mieux

on réduit les coûts de production. Ces opérations de routine utilisent des procédures qui permettent de travailler de façon prédictible et efficace. Opération : Entretien des routes communales, des chemins et des canalisations Les opérations de déneigement, de nettoiement, de commodité et de sûreté ne sont pas considérées comme des projets. Ce sont des activités de routine. L’entretien des espaces verts, des fossés, des stations de pompages, des dépotoirs et des canalisations sont des opérations et non des projets.

Exemple 25 : Opération : un projet n’est pas une opération

Un projet a un début déterminé et une fin déterminée. Passée la date de clôture, le projet entre souvent dans un mode d’opération et de maintenance. Quand un site Web rentre en mode opérationnel, il ne reste plus qu’à l’entretenir au quotidien, le faire vivre. Les petites modifications apportées au site feront partie des opérations de maintenance. En revanche, les grandes modifications du site, nécessitant une transformation considérable, ressortiront d’un projet de changement (change request) en vue d’améliorer le site. Ces demandes de changement (change request) ont un

début et une fin déterminés et sont donc temporaires le site passant, à terme, à nouveau dans un mode opérationnel. Un projet passe donc en mode opération lorsqu’il touche à sa fin (Figure 11 : Projet vs Opération). Dans les estimations de coûts de projet, il faut tenir compte des coûts opérationnels au terme du projet également. Un projet peut également être organisé pour mettre fin à une opération de routine, le démantèlement d’une usine nucléaire, par exemple. Les projets peuvent également troubler le cours d’une opération de routine. Une des caractéristiques d’une opération est qu’elle se base sur un modèle de

coût OPEX (Operational Expenditure ou dépenses de fonctionnement ou d’exploitation). Les projets, par contre, s’appuient souvent sur un mode de coûts CAPEX (Capital expenditures ou dépenses d’investissement) car un projet est un investissement, d’où l’importance du retour sur cet investissement et la date où l’on atteint le seuil de rentabilité. Un projet peut utiliser un mixte de CAPEX pour les matériels et OPEX pour les ressources humaines qui travaillent sur le projet.

Un projet a un début déterminé Tout projet a un début déterminé,

survenant après la signature d’un document officiel dans lequel on reconnaît formellement l’existence du projet, et autorise le manager du projet à engager les ressources et le budget nécessaires pour le mener à bien dans un délai établi. Charte de Projet Dans le guide PMBOK®, la charte de projet représente ce document officiel. La signature du document d’initiation du projet (Project Initiation Document) officialise le début d’un projet pour les organisations qui utilisent la méthodologie Prince 2.

Contenu de la Char 1. Historique du projet

2. Les besoins du business motiv 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

bénéfices futurs du projet (Bu Objectif du projet Facteurs critiques de succès d Coûts du projet et modèle de Énoncé préliminaire du scope La population impactée par le Les processus impactés par le Les exigences fonctionnelles c Frontière du projet : ex dépendance, hypothèses Liste des stakeholders avec le La structure de gouvernance e Risques Initiaux Macro-planning - Chronologie projet.

Exemple 26 : Contenu de la Charte de Projet

Quand on est nommé Manager de Projet, il faut toujours réclamer le document officiel signé par tous les stakeholders du projet, ainsi que par le sponsor. Il ne faut jamais commencer un projet sans sa charte. Savez-vous quelle est la question que tout Manager de Projet doit se poser avant d’accepter la responsabilité de manager un projet ? Ce n’est pas du tout le scope mais, bien avant toute chose, la question du pourquoi vouloir lancer ce projet. Pourquoi l’organisation veut-elle se donner la peine et dépenser de l’argent pour entreprendre ce projet ? Pourquoi devriez-vous vous démener jours et nuits pour assurer la réussite de ce projet ? Le document officiel, la charte du projet ou

autre PID, doit répondre à tous ces pourquoi. Ce document décrit la vision du projet que tous les stakeholders devraient comprendre et partager et constitue surtout leur engagement à atteindre les objectifs de ce projet, d’où le besoin de signature de ce document lien unissant tous les stakeholders durant le projet. Si la charte de projet est signée par une personnalité très haut placée dans la hiérarchie d’une organisation alors, vous verrez que vous n’aurez aucun mal à obtenir le support financier et même émotionnel du plus grand nombre. En revanche, si le document n’est pas signé ou signé par une personne sans grande influence dans l’organisation, vous aurez sans doute

plus de difficulté à capter l’attention des autres sur le projet. L’une des raisons de l’échec d’un projet est le manque de support de la hiérarchie et des stakeholders influents. Ce document peut comprendre une page pour un simple projet ou plusieurs pour un projet plus conséquent. Il revient à chaque organisation, selon les types et la taille de ses projets, de définir la méthodologie de management de projet, les processus et techniques, les outils et templates à utiliser, ainsi que de déterminer quelles seront les personnes habilitées à signer la charte. Une fois la charte de projet signée par les parties prenantes, notamment par le

sponsor, le manager du projet est officiellement tenu responsable de livrer le projet dans les temps et le budget alloué. Il est responsable du choix de la méthodologie à suivre pour mener le projet à bien. Il est donc également du ressort du Manager de Projet de déterminer le moment propice pour organiser la réunion de kick-off de son projet. L’objectif d’une réunion kick-off est de regrouper, pour la première fois, l’ensemble de l’équipe projet. Si l’équipe est virtuelle, on réunit tout le monde dans la même salle. Toutes les informations nécessaires et disponibles à ce moment pour mener à bien le projet sont ainsi livrées à l’équipe.

1. 2. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Sujets à aborder pendant l Historique du projet Objectif du projet 3. Le cycle de vie, la choisie pour le proj Les différentes phases du proj La durée du projet (si connue) du projet La présentation des stakeholde La composition de l’équipe pr La matrice de responsabilité (R La communication Les standards, pratiques et pro projet Les outils à utiliser La prise de conscience des livr phase et par qui

13. Explorer la façon de travailler virtuelle Exemple 27 : Sujets à aborder pendant la réunion de kick-off

Genèse d’un projet Il faut savoir qu’il se passe un certain nombre de choses avant qu’un projet ne démarre. La genèse d’un projet débute au moment du rêve ou de la vision de réaliser un projet et se clôture à la signature de ce document officiel, autorisant formellement le démarrage du projet. Celui-ci peut se révéler être un long périple, chaotique, où beaucoup de facteurs rentrent en jeu : des enjeux stratégiques pour la

compagnie, peut-être même de raison politique ou légale, la négociation d’un contrat, etc. Projets identifiés lors de la planification annuelle Chaque organisation dispose de procédures (ou processus) pour identifier et autoriser le lancement de projets en fonction de la taille de celuici. Généralement, le lancement de nouveaux projets se décide lors de la planification annuelle ou semestrielle en fonction des compagnies. Les budgets y sont déterminés pour les portfolios, les programmes et projets en cours et les nouveaux projets ou programmes y sont identifiés parce qu’ils peuvent mieux

répondre aux buts, objectifs ou stratégies de l’organisation pour les années à venir. Ces moments sont, pour les managers de programmes ou de projets, l’occasion de défendre leurs programmes ou projets. Pour les projets ou programmes en cours, les managers qui ont du mal à comprendre comment leurs budgets sont dépensés et qui ne peuvent prouver que leurs travaux sont ceux qui ont le plus de valeur, risquent de se retrouver, un jour ou l’autre, en proie au malaise et au doute. Le management de portfolio, que l’on verra plus tard, permet à votre organisation de répondre aux questions les plus fondamentales et les plus complexes concernant le travail

accompli et la valeur produite. Projets identifiés à tout moment en cours d’année D’autres projets sont identifiés en cours d’année, hors de la planification annuelle ou semestrielle. Des projets dont la réalisation s’est vue obligatoire par la force des choses, des événements imprévus, d’un accident, d’un problème à surmonter rapidement, etc. Ces projets n’étaient pas planifiés. Le projet de Toyota, où le constructeur rappelle 400.000 de ses voitures hybrides pour un problème dans le système de freinage, par exemple, est dicté par la force des choses. Un autre exemple est celui d’une organisation

déployant de la téléphonie sur IP, qui s’aperçoit que son réseau ne supporte pas la voix. Hors, pour une ToIP, le réseau doit être clair. Investir donc préalablement dans les réseaux. L’erreur peut être de choisir le lancement d’un projet parce qu’il nous faut tout simplement liquider un tropplein de budget pour éviter d’en perdre une partie l’année suivante, pour résoudre un faux problème, ou encore lorsque l’on est limité par le budget ou le temps. Mais revenons à cette période de gestation, d’identification et d’autorisation d’un projet : elle comporte plusieurs phases qui s’écartent

du propos de cet ouvrage puisque nous nous intéresserons plutôt au projet à partir de son démarrage officiel. Toutefois, je vais donner un aperçu succinct de la genèse des projets dans ce paragraphe, en commençant par décrire les raisons d’un projet, pour terminer ensuite par son mode de sélection au sein des organisations. Le parcours, depuis le désir de réaliser un projet au moment de son démarrage officiel, peut être illustré de façon synthétique à travers le cycle de vie du business simplifié ci-dessous :

Figure 12 : Cycle de vie du Business

Phase 1 : Besoin de projets et leur finalité La finalité du projet est la toute première question que tout Manager de Projet devrait se poser avant d’accepter son management. Pourquoi conçoit-on ce projet ? La charte de projet, nous l’avons vu, répond à cette question en

offrant la vision du projet, en cernant le problème à résoudre et surtout, en définissant les critères de succès du projet. Plus la vision est claire, plus ténu sera le besoin de motivation : une simple vision forte de l’objectif du projet permet d’établir facilement une approche hiérarchique top-down de la structure des tâches (WBS) à réaliser. Le management du projet devient plus facile quand l’on garde toujours sa finalité en vue. En somme, un manager ne saurait livrer proprement un projet s’il n’en comprend pas l’essence, le but et les raisons d’être et encore une fois, la charte du projet en offre la réponse. Selon le PMBoK®, les projets sont

habituellement autorisés à la suite d’une ou de plusieurs des considérations stratégiques suivantes :

1. Demande du marché : Les entreprises ont besoin d’exister sur le marché si elles veulent survivre et la tendance du marché les oblige constamment à adapter leurs stratégies pour faire du profit. Elles entreprennent donc des projets pour demeurer compétitives.

Projets lancés suite à la deman 1. Le marché du Sky altitude, projet d’équ Wifi), par exemple, est en f saturé et il faut s’attendre entreprennent des projets su passagers d’un avion de co

chatter… - tout ce que l’on ef 2. Le marché demande égalemen écologiques sur les énergies re qui est polluant et dont le ra déjà perceptible. Ainsi, p entreprises se sont lancées caractère écologique en créa énergies renouvelables : éner photovoltaïque), hydraulique, de la biomasse. Exemple 28 : Projets lancés suite à la demande du marché

Exemple 29: Demande du marché de projet écologique – WADI RUM

Exemple 30: Demande du marché de projet écologique - General Electric Ecomagination

2. Opportunité stratégique, besoins d’affaires : un changement de situation ou de configuration comme la

faillite d’un compétiteur, un événement quelconque survenu quelque part qui change les données du marché comme l’indépendance d’un pays ou la possibilité de tirer avantage d’une situation actuelle peuvent être vus comme des opportunités stratégiques amenant des bénéfices - premier objectif du business. Par ailleurs, le business peut aussi tout simplement avoir besoin d’affaires dans une région. Pour ces deux raisons, les organisations autorisent le lancement d’un projet.

Projets lancés suite à une opp d’affaires 1. Les compagnies pét

opportunité stratégique dans qui a rendu indépendants les En effet, elles avaient beso monde et cette situation leur a pétrolières locales. 2. Le projet d’oléoduc BTC trav (Géorgie) et Ceyhan (Turqu inspiré un film de James Bon stratégie d'indépendance politi avaient grand besoin de ce économiques. Il faut souligne BTC a été l’un des plus impo du XXIe siècle. 3. La création des produits déri des produits courants ou ser d’un aéroport pour recevoir aérien - reste une opportunité d’affaires. 4. La réalisation d’un projet d’

l’épidémie de grippe A, en compagnies pharmaceutiques. 5. Différents projets sont lancés de catastrophe naturelle (Haï Afghanistan, etc.). Exemple 31 : Projet lancé suite à une opportunité stratégique ou de besoin d’affaires

6. Demande du client : la plupart des projets démarrent également parce qu’un client a besoin de satisfaire ses besoins stratégiques. En temps de conjecture économique favorable, nombre de projets sont entrepris par les clients. En revanche, en temps de crise économique, on constate moins de demande de la part des clients, donc moins de projets et certaines entreprises, dont les sociétés de

services, sont les premières victimes de cette diminution de la clientèle.

Projets lancés suite à la demande du 1. Le Stade de France : Le réalisation, à 400 millions d’un grand stade en région parisienn personnes. 2. Les Transports de Londres, organe lancé un appel d’offres pour remplac 1920 et qui étaient presque en r Manager de Projet car on y ren 100.000 voitures et 800 trains par jo quotidien circulent sur ces deux p intéressant pour le Manager de Proj circulent 18 heures durant sans s’effectuer pendant les 6 heures rest pire encore, la circulation sur l’a

Heathrow express, était permise 24 faire fermer le pont 3h par jour po encore plus intéressante sur le man Ce projet a été d’une grande réu n’aiment pas ce genre de pression ailleurs. On rêve tous de grands proj Exemple 32 : Projets lancés suite à une demande du client

Nous connaissons tous l’adage affirmant que le client est roi. Le client se montre toujours exigeant et s’attend à ce qu’on lui offre toujours plus en payant moins. Tout Manager de Projet devrait pouvoir gérer les attentes du client en définissant bien le scope d’un projet, car le client viendra toujours le modifier ou y ajouter un nouvel élément. Ainsi, le Manager de Projet devrait toujours mettre en place

un mécanisme de management de changement intégré sur tout projet. Un changement de scope entraîne un autre projet avec un budget et un délai différents de ceux définis précédemment.

3. Innovation, avancées technologiques : Les projets de Recherche et Développement(R&D) motivent les organisations qui veulent se trouver à la pointe de la recherche et du développement de nouveaux produits ou résultats. Les avancées technologiques, issues des résultats des projets R&D, obligent les organisations à adapter leur stratégie. Celles qui ne s’adaptent pas signent leur mort. Il leur faut se renouveler,

sinon la concurrence s’empare du marché, généralement par la réalisation de projet dont le résultat, le produit ou le service possède un caractère novateur. En effet, il est nécessaire que les organisations innovent, développent une nouvelle façon de procéder pour éviter leur dislocation, car les concurrents, eux, ne s’arrêtent jamais. L’innovation est le maître mot du « forward thinking » (penser vers l’avant) des compagnies actuelles pour exister sur un marché et cela se fait à travers des projets. Les avancées technologiques permettent aussi aux entreprises de lancer d’autres projets, qui n’étaient pas du domaine du possible sans la percée ou

la découverte de ces progrès.

Projets lancés suite à l’innovation o Les grandes avancées dans ont permis aux entreprises en plus petits. Un nanomètre est un m si petite qu’il est difficile de se la rep dans ce domaine a permis le dévelop nano : Ipod, test de grossesse, crèm ménagers, télévision à écran plat, portables, portables, etc. Plusieurs m ces nouvelles technologies. D’autres applications pour la santé, l’énergie, avancées permettent aux entreprises marché avec des nouveaux produits mettent en place à travers des projets. Exemple 33 : Projets lancés suite à l'innovation ou aux avancées technologiques

4. Obligations légales : les organisations sont obligées de lancer des projets pour s’aligner sur les lois ou réglementations qui viennent d’entrer en vigueur.

Projets lancés suite aux obligat 1. Les phosphates s domestiques en Fran cette date, les entreprises domestiques contenant des p des projets pour enlever les p produits. 2. Un autre exemple d’obligatio projet d’établissement pour c définir l'ensemble des choix pé particulières que l'équipe éd mettre en œuvre, en collabora partenaires (parents, élèves,

économique), pour réaliser le du pouvoir organisateur. Le du public et de l'environnemen 3. Enfin, un autre exemple est pouvoir bénéficier de l’aide f l’Union Européenne, a pour o d’analyse coût-bénéfice de l’im ou d’infrastructures de tran demandé. Exemple 34 : Projets lancés suite aux obligations légales

Identification d’un projet Nous venons de voir les besoins nécessitant le lancement de projets. Mais le processus d’identification de ces besoins varie d’une organisation à l’autre. Les organisations les identifient ordinairement en utilisant l’une ou les

deux approches suivantes : Une approche descendante (TopDown) : l’expression des besoins d’un projet provient du haut de la hiérarchie, du comité de direction ou de toute personne décidant des stratégies de l’organisation, de l’optimisation de son business. Cette approche est très orientée vers l’objectif du business. Elle peut représenter un inconvénient car, à ce niveau de décision, on ne connaît pas forcément les détails de la réalité du terrain. Quelques compagnies utilisent une approche systématique top-down, pour n’identifier que les programmes ou les initiatives plus conséquentes.

Une approche ascendante (Bottom-Up) : l’expression des besoins de lancer un projet s’effectue suivant un processus de soumission de la part des niveaux tactiques ou opérationnels de l’organisation, qui cherchent à optimiser les opérations ou les processus. La plupart des compagnies disposent souvent d’un système en place pour solliciter les propositions. L’inconvénient de cette approche est que la hiérarchie ne tient pas souvent compte de ces demandes. Enfin, dans les deux approches, généralement, les managers de projet ne participent pas à cette phase

d’expression des besoins de projets. En général, elle est souvent menée et exprimée par le Business, à moins qu’elle n’émane directement du conseil d’administration de l’organisation ou des niveaux opérationnels comme le manager de programme ou de portfolio. Phase 2 : Sélection des projets par Business Case En général, les informations requises pour prendre les décisions concernant la sélection et la hiérarchisation ou plutôt la priorisation (privilégier un projet par rapport à un autre) d’un projet sont généralement contenues dans un document intitulé le Business Case ou le cas d’affaires. Chaque Manager de Projet possède sa propre façon de faire.

Personnellement, je préfère décortiquer le Business Case puis la Charte du Projet avant de m’embarquer sur un nouveau projet. Cela n’a aucun sens d’entamer un projet si les raisons pour lesquelles il a été choisi ne sont pas rédigées proprement et signées par la hiérarchie.

Business Case document de projet. C’est don d’un projet d’envergure. Ce docu projet, son plan de financement, engager pour le réaliser, et traite e L’objectif du business case pour 1. Quels sont les bénéfices et l Business ? 2. Pourquoi ce projet est-il

3. 4. 5. 6.

financement ? Où le projet doit-il être implé Quand le projet doit-il être im Quelles sont les personnes projet ? Comment peut-on implément

Définition 6: Business Case

Le Business Case ou le cas d’affaire : c’est le document qui, d’un point de vue business, offre toutes les informations sur les bénéfices ou retour sur investissement (ROI) que l’on peut espérer du projet. Ce document permet de savoir si le projet répond aux besoins du business et si cela vaut le coup que l’organisation s’y investisse. Ce document démontre la viabilité de

chaque projet. Un business case n’est qu’une “meilleure estimation” à un moment donné et ce document est donc à mettre à jour tout au long du projet, si celui-ci est sélectionné. On peut ainsi évaluer, en fonction des progrès, si le projet peut encore atteindre le bénéfice escompté ou non. Un bon business case est une série de “meilleures estimations” bien étayées, qui sont continuellement vérifiées et mises à jour. On y voit si les bénéfices attendus seront toujours au rendez-vous. Ce document offre une évaluation et une validation économique exhaustive de l’intérêt de lancer le projet. Il décrit les raisons et offre une justification du projet basée sur les

coûts estimés, les risques impliqués et les futurs bénéfices et valeur attendus. On détermine dans ce document les bénéfices tangibles (quantifiables et mesurables) et intangibles (qualitatifs, tels l’impact sur l’image de l’organisation) de lancer le projet. Il est très important que les bénéfices tangibles soient aussi mesurables que possible afin de disposer de bases de comparaison pertinentes et de pouvoir comparer avec un maximum d’exactitude les différentes propositions de projets. Ceci pourrait donner l’impression que monter ce document nécessite beaucoup de travail, ce qui est le cas. Mais il ne faut pas oublier que ce document est

utilisé pour distinguer les projets qui obtiennent un financement de ceux qui n’en obtiennent pas. Dans certaines organisations, en plus de ces documents, il faut tenir compte des considérations politiques ou d’autres lobbyings très forts d’un individu ou groupe d’individus pour le lancement d’un projet.

Un projet présente une fin déterminée lorsque ses objectifs sont satisfaits Le but du projet est atteint lorsque ses objectifs sont satisfaits. L’effort temporaire pour créer un produit, un service ou un résultat se termine lorsque le produit, le service ou le résultat désiré est livré et rencontre ou excède la satisfaction des stakeholders. Le projet a résolu le problème pour lequel il a été créé. Un projet a atteint ses objectifs quand tous les critères de succès définis dans

la charte de projet ont été respectés. Au début du projet, le Manager de Projet définit les critères d’acceptation du produit, du service ou résultat attendu du projet. Ce sont ces critères que l’on vérifie au moment du handover ou livraison du résultat au client. Si ces critères ne sont pas définis à l’avance, on peut s’attendre à un désaccord, mécontentements sur le produit, service ou résultat livré. Il ne faut jamais tomber dans ce piège. Et, de toute façon, sans avoir défini à l’avance les critères de succès, on ne pourra jamais considérer qu’un projet a atteint ses objectifs et est une réussite. Ces critères évitent donc les ambiguïtés à la fin du projet quant au résultat attendu. Il n’y a rien de pire

qu’un projet que l’on ne peut pas clôturer parce que son commanditaire n’en est pas du tout satisfait. Un tel document peut être un cahier de tests où la réussite de ces derniers signerait le succès du projet. Si les objectifs sont bien définis de façon SMART, alors le Manager de Projet n’aura aucun mal à vérifier si les objectifs spécifiques du projet ont été respectés. Ces objectifs sont techniques, fonctionnels, temporels et financiers. Comme nous le verrons dans la section Management de Projet, le Manager de Projet aura mis en place des métriques (délai, coûts, qualité, bénéfices, ressources) pour mesurer le progrès et la performance du projet tout au long du processus. Le système de

mesure de performance et de progrès doit être défini à l’avance, au même moment que le scope. Ce système de mesure quantitative doit inclure le coût, le délai, les risques, la qualité, les bénéfices et les ressources. À chaque milestone atteint dans le projet, le Manager de Projet doit réaliser le bilan à cet instant de ses métriques, et doit également mesurer ou estimer, suivant ces indices donnés, ce qui lui reste à accomplir pour mener le projet à bon port (objectifs atteints). Le management de projet consiste à influer sur ces métriques pour atteindre les objectifs du projet. « Celui qui n'a pas d'objectifs ne risque

pas de les atteindre. » Sun Tzu Ce n’est qu’en suivant ces métriques que le Manager de Projet s’assure que le projet a tenu toute sa promesse en livrant le produit, le service, le résultat voulu tels qu’ils ont été spécifiés par le client ou le sponsor. Vérifier si le projet satisfait ses objectifs ne se fait donc pas à la dernière minute, mais plutôt tout au long de sa phase d’exécution et de contrôle. Avec le système de métriques mis en place, on effectue en permanence cette vérification de la qualité des livrables et de la viabilité financière du projet, afin de ne pas avoir de surprise au moment de la livraison. Nous

verrons, dans la section 4 : management de projet, les seuils à franchir pour passer d’une phase à l’autre sous des conditions de Go ou No-Go, pour poursuivre le projet en fonction des métriques. Ainsi, on ne passe pas à l’étape suivante si les livrables de la phase précédente ne se sont pas avérés concluants par exemple, ou si l’on ne peut plus atteindre les objectifs par manque de temps ou de budget. Si la charte du projet marque le démarrage officiel d’un projet selon PMBOK®, le processus « clore le projet » consiste à finaliser toutes les activités. Les objectifs du projet sont atteints, on clôt aussi tout

approvisionnement, les souscontractants. Nous verrons en détails, dans la section 2 : management de projet, le groupe de processus de clôture de projet car il y a un certain nombre d’actions à mettre en place et à effectuer pour clore proprement un projet. Un bon Manager de Projet doit toujours clore son projet de façon efficace et sans ambiguïté avant de passer à un autre. Le Manager de Projet doit clore proprement le projet en réalisant l’inventaire des travaux à terminer et passer des contrats avec les services opérationnels et fonctionnels de l’entreprise afin que ces derniers prennent en charge ce qu’il reste à faire.

Nous verrons plus tard, dans la section 4, les processus qui permettent de clore proprement un projet.

Un projet a une fin déterminée lorsque les objectifs du projet ne sont plus atteints ou ne sont plus jugés utiles Malgré les efforts du Manager de Projet, il arrive qu’un projet soit arrêté en cours de route pour diverses raisons. Livrer le projet dans les délais et dans le budget peut ne pas être suffisant, si le projet ne rend pas la qualité attendue, ou pire, s’il ne répond plus aux besoins du business, comme un retour sur investissement qui

ne sera plus atteintpar exemple, ou encore, si le projet ne résout plus les problèmes pour lesquels il a été lancé. On a vu, dans les paragraphes précédents, que la performance du projet est mesurée continuellement tout au long du processus par le système métrique mis en place en début de projet. A partir du moment ou une ou plusieurs variables du système métrique (délai, coûts, bénéfices, qualité, risques, ressources, etc.) ne conviennent plus ou ne peuvent plus être contrôlées, il devient logique d’interrompre le projet. Par exemple, le délai ne peut plus être atteint, les coûts ne peuvent plus être pris en charge, il faut un budget supplémentaire que personne ne veut financer, les bénéfices

attendus du projet ne seront plus atteints, les fonctionnalités que l’on cherche à implémenter ne pourront pas l’être et la qualité du projet en pâtira sont autant de facteurs qui empêcheront d’atteindre les objectifs du projet. Il faut toujours mettre en place, en début du projet, un mécanisme de Kill Switch qui prédéterminerait les conditions à partir desquelles il n’est plus raisonnable de poursuivre et d’investir sur un projet. « La folie est de toujours se comporter de la même manière et de s’attendre à un résultat différent. » Albert Einstein

La suggestion de l’arrêt d’un projet doit toujours venir du manager du projet. Une décision d’arrêter un projet doit être finale. Il n’y a pas de honte à abandonner de tels projets, le pire serait de persister par orgueil ou pour cacher ses erreurs. Un Manager de Projet doit savoir évaluer et suspendre son projet ou, en tous cas, proposer son interruption, et c’est à l’organisation par la suite d’en évaluer la poursuite ou non. Mais jamais cette dernière ne persiste à poursuivre le projet pour des raisons inconscientes, bien sûr, mais bien en faisant du damage control, en limitant autant que possible les dégâts. La charte du projet confie au Manager de Projet la

responsabilité de l’issue de son projet. C’est intelligent de la part du Manager de Projet d’arrêter le saignement d’un projet en l’interrompant complètement. Le plus tôt est le mieux pour ne pas gaspiller davantage d’argent et de ressources. Projets arrêtés en cours de route California DMV ("California Department of Motor Vehicles") a lancé en 1987 un grand projet pour introduire de nouvelles technologies dans la gestion des permis de conduire. Le projet a été arrêté en 1993, après avoir coûté 45 millions de dollars. En fait, le projet était volontariste ; il n'avait convaincu ni les dirigeants ni

les utilisateurs et ses spécifications étaient confuses. American Airlines: un projet de réservation de chambres d'hôtel et de location de voitures a été abandonné en 1994 après avoir coûté 165 millions de dollars. On explique l'échec par le trop grand nombre de partenaires impliqués, l'imprécision et l'instabilité des spécifications, le manque d'implication des utilisateurs. Exemple 35 : Projets arrêtés en cours de route

Quand un Manager de Projet sent que le projet lui échappe ou qu’il ne le contrôle plus totalement, son sens de l’éthique et son honnêteté intellectuelle doivent l’obliger à suggérer son interruption, au lieu de persister dans le mauvais chemin

en prétendant livrer ce que l’on ne peut pertinemment plus livrer. Dans certaines organisations, il existe des managers de projets spécialistes des missions de recherche et de sauvetage de projets en pleine détresse. Ce n’est pas une honte de faire appel à eux. Les facteurs d’échec d’un projet Un échec survient lorsque le projet n’a pas fonctionné ou lorsqu’il ne répond pas aux attentes des stakeholders. Un projet arrêté en cours de route est un échec. On a vu que plusieurs facteurs entrent en jeu pour expliquer les échecs des projets. En général, ces facteurs tournent toujours autour des éléments suivants :

Les choix des ressources : le destin d’un projet est déterminé, dans cet ordre, par les ressources, les processus et la technologie. Les ressources, à commencer par le Manager de Projet, n’ont pas été à la hauteur car elles ne disposaient pas des compétences et du savoir-faire nécessaires pour mener à bien le projet. La mauvaise définition de l’objectif stratégique ou du problème à résoudre : les initiateurs du projet n’ont peut-être pas bien cerné les objectifs stratégiques ni le problème à résoudre. Les projets ont été lancés pour les mauvaises raisons ;

la collecte incomplète.

des

exigences

est

Le changement de scope non contrôlé (scope creep) : les exigences survenues en cours de projet n’ont pas été intégrées proprement. L’expansion des exigences peut créer un désastre sur un projet. Le manque de support de l’exécutif et des stakeholders : il pourrait y avoir une implication passive ou une insuffisance, voire un manque total de support de la part des stakeholders. La traversée du désert du Manager de Projet

Quand un projet échoue, il est inéluctable pour le Manager de Projet d’être exposé aux critiques. Jusqu’à preuve du contraire et pour ceux qui ne connaissent pas en détails le projet, l’échec du projet sera toujours attribué au Manager de Projet : on parlera de sa compétence administrative, humaine et technique. On parlera, à tort ou à raison, des séries de mauvaises décisions prises par le Manager de Projet, qui ont fait que le projet a déjà consommé la totalité de son budget alors que l’on se trouve seulement à mi-chemin par exemple, ou que le retard de plusieurs mois dans la livraison du projet est imputable à une mauvaise gérance ou encore, que bien que les retards étaient récupérables, il

n’a pas su proposer de mesures et d’actions correctives appropriées. On dira encore que le Manager de Projet s’est noyé et enfermé dans des livrables ou des processus et méthodologies trop lourds à suivre et qu’il n’a pas fait preuve de pragmatisme pour garder sa mission en tête. Le Manager de Projet va entendre de tout. D’ailleurs, quand un projet fonctionne, on félicite souvent l’équipe projet pour son succès, alors que s’il échoue, on s’en prend exclusivement au Manager de Projet. On ne mentionne jamais le manque de dynamisme de l’équipe durant un projet où une certaine inertie s’installe et devient source d’échec.

Dans ces moments-là, le Manager de Projet peut ressentir une grande solitude et traverser un long désert par la suite, car personne ne voudra confier un projet d’envergure à un manager qui vient d’en rater un. Le Manager de Projet doit faire preuve d’une grande humilité et recommencer par de petits projets.

Un projet peut faire partie d’un programme ou d’un portfolio Chaque organisation possède sa propre structure. Mais, en général, on peut constater que les projets font partie des portfolios ou des programmes comme le montre la figure ci-dessous où le

portfolio X comprend plusieurs projets et programmes et où les programmes se subdivisent à leur tour en projets.

Exemple 36:Portfolio de projets et de programmes

Portfolio Une organisation peut disposer de plusieurs portfolios de projets et de programmes. C’est à ce niveau que l’on définit ses objectifs stratégiques. Le portfolio s’aligne clairement avec les objectifs stratégiques de l’organisation fixés par ses leaders. Les objectifs stratégiques peuvent être décomposés en sous-objectifs qui peuvent être des projets. Mais si ces projets sont trop importants, on les décompose euxmêmes en sous-projets, le projet devenant donc un programme constitué à son tour de plusieurs projets. En

observant des projets depuis la perspective du portfolio, nous pouvons considérer les projets moins comme des efforts individuels que comme un ensemble interconnecté. De plus, l’interdépendance des projets ou programmes met en évidence leurs objectifs et buts respectifs qui, mis ensemble, représentent les objectifs du portfolio, et évitent les jeux politiques, moins objectifs, sur la sélection des projets. On y trouve moins de projets redondants ou se chevauchant et surtout, on y trouve une organisation sensée. L’analyse de Portfolio permet d’examiner des questions telles que : « Comment les ressources pour le Projet A1 seront-elles impactées si le Projet A2

ou le Projet B se voit retardé ? » Elle offre également une optimisation de l’allocation des ressources associées aux projets ou programmes. Une organisation via portfolio ne peut qu’améliorer la communication au sein de l’entreprise entière. Portfolio V2D (Vidéo, Voix et Données) Dans le cadre de réduction de coût de communication, de voyages et d’opérations, un grand groupe international, présent dans plus de 100 pays dans le monde, veut capitaliser sur les technologies émergentes et fait de l’implémentation de la nouvelle technologie émergente à base de téléphonie sur IP (ToIP), un objectif

stratégique. Pour ce faire, il a créé un portfolio qu’il a nommé V2D pour la convergence du Triple play Voix, Vidéo et Données. Nous avons vu que les portfolios de projets révèlent les valeurs et pour le portfolio V2D, celles-ci pourraient être les suivantes : Réduction significative de coût en termes de communication locale ou internationale, de voyages et d’opérations. Réduction du temps de latence du business en augmentant le temps de réponse des employés mobiles qui peuvent cette fois accéder aux données de l’entreprise à tout moment, quelle

que soit leur situation au sein de l’entreprise ou dans un bureau virtuel en travail à distance (chez le client ou chez soi). Favoriser l’équilibre entre le travail et la vie sociale en simplifiant la façon de travailler, tout en augmentant la productivité des équipes, qui sont souvent virtuelles car situées à plusieurs endroits. Participer à la prise de conscience écologique en offrant la possibilité du travail à distance avec un bureau virtuel. Ceci peut être une première réponse à la congestion du trafic routier en permettant le télétravail à l’employé. Exemple 37 : Un portfolio de programmes et de

projets

Le portfolio dévoile les valeurs d’une vision ou d’une opportunité qui peuvent rapporter des bénéfices à l’organisation. Le portfolio souligne aussi les menaces qui pèsent sur l’organisation et implémente, à travers les projets ou les programmes, les plans pour contourner ces menaces ou les transformer en opportunités. Le portfolio permet donc le changement stratégique dans une entreprise. D’ailleurs, un bon management de portfolio peut servir d’accélérateur de sortie de crise en implémentant les bons programmes et les bons projets. Il faut savoir que les organisations qui n’évoluent pas risquent l’obsolescence.

Exemple 38: Portfolio

Programmes Le programme développe les valeurs, les opportunités, les changements de stratégie. Juste en dessous du portfolio dans la pyramide, on remarque les projets et programmes qui peuvent être

interdépendants ou directement liés, mais qui visent ensemble à atteindre l’objectif du portfolio. Afin de mieux gérer et implémenter le portfolio, on le divise en projets indépendants qui ne renvoient qu’au portfolio, ou en plusieurs programmes composés de projets interdépendants. Un programme représente donc plus qu’une addition de projets, car ces projets sont interdépendants et la réussite ou l’échec d’un projet influe sur les objectifs du programme, et donc du portfolio. Programme issu du portfolio V2D Programme Voix et Données : ce programme est composé de 3 projets

interdépendants : a) Projet ToIP : via plusieurs projets, il consiste en la migration vers la téléphonie sur IP de tous ses sites dans le monde. En effet, comme toute innovation technologique, la ToIP doit non seulement simplifier le travail mais aussi faire économiser de l'argent. Les entreprises dépensent énormément en communications téléphoniques, or le prix des communications de la ToIP (Téléphonie sur IP) est dérisoire en comparaison. En particulier, plus les interlocuteurs sont éloignés, plus la différence de prix est intéressante. Importantes réductions mises en évidence pour des communications

internationales, celles-ci deviennent encore plus intéressantes dans la mutualisation voix/données du réseau IP inter-sites (WAN). Dans ce dernier cas, le gain est directement proportionnel au nombre de sites distants. b) Projet Données : l’objectif du projet est d’offrir un service de données en implémentant les dernières technologies et infrastructures pour accéder à vos mails, aux informations de l’entreprise ou effectuer des remontées terrain à partir de votre mobile ; d’assurer, enfin, une sécurité d’accès aux données sensibles et confidentielles. c) Projet Convergence : il se concentre sur la convergence

numérique, à savoir, le développement d'appareils multifonctionnels. Bénéfices pour l’usager : une réduction des coûts des produits grâce à des économies d'échelle de services incluant l’intégration par l’informatique de l’ensemble des moyens de communication du consommateur (voice, e-mail, web, fax, etc.). Programme Vidéo : ce programme se focalise sur le développement de services et produits offrant la possibilité de vidéoconférence et de messageries instantanées. Il permet ainsi à l’organisation de réduire ses coûts de déplacement tout en offrant à ses employés la possibilité de réunions fréquentes.

a) Projet Vidéoconférence : le but de ce projet est d’offrir un service unique global de vidéoconférence à déployer sur tous les sites de l’entreprise. La valeur ici est la réduction du coût en évitant les fréquents déplacements de ses équipes pour les réunions en face-à-face. Le service peut offrir également un système de télé-présence permettant de voir ses interlocuteurs à l'échelle 1, avec la sensation de pouvoir se regarder 'les yeux dans les yeux'. b) Projet IRC : offrir un produit permettant d’établir une communication Audio/Vidéo de PC à PC facilitant ainsi le travail de deux collègues situés sur des

sites distants. Un produit unique de messagerie instantanée, principalement sous forme de discussions chats, qui permet également le transfert de fichier. Exemple 39 : Programmes issus du Portfolio V2D

Le programme développe la valeur, les opportunités, les changements de stratégies. Un programme intègre plusieurs projets, mais il est plus qu’une addition de projets, il développe une valeur en coordonnant les bons projets. Un programme type englobe plusieurs projets comprenant des dépendances mutuelles qui, collectivement, remplissent l’un des objectifs du business.

Projets C’est ce que l’on peut voir en bas de la pyramide, les projets interdépendants. Car si le programme développe de la valeur, le projet livre de la valeur. Un projet peut se réaliser de cette manière, indépendamment de tout, mais en général, il découle d’un programme ou directement d’un portfolio comme l’ont démontré les exemples ci-dessus. Le Manager de Projet doit pouvoir cheminer vers le haut car son projet doit répondre au besoin fixé par les portfolios managers, eux-mêmes répondant à un besoin stratégique à plus haut niveau. Votre projet est une réussite s’il satisfait aux stratégies fixées par le

business. Même s’il a été livré dans les temps et dans le scope, s’il n’est plus aligné avec l’objectif stratégique de l’organisation, il équivaut alors à une perte de temps et d’argent, mais il aura constitué un bon exercice pour pratiquer le PM. On a donc bien vu que les projets peuvent êtres indépendants comme dériver également de portfolios ou de programmes. Le projet ETC (Environnement de Travail Collaboratif) mentionné plus haut fait partie, par exemple, du portfolio V2D.

Les Projets Intégrés iss Recherche et de Dével

Commission Européenne Les objectifs du 6e Programme Cadre R vision du Conseil Européen sous-tend l’objectif de Barcelone 2002 de faire plus compétitive et la plus dynamique dans le monde. Pour la mise en œuvre de cet Esp Commission européenne a mis en place a) Les réseaux d’Excellence : dont la fragmentation des efforts de rec restructuration et une intégration dur b) Projets Intégrés : dont les objec sont de "Favoriser la compétitivité e problèmes sociétaux majeurs." Un e haut qui consiste à améliorer no d’Afrique occidentale et de son im chimique et biologique à l’échelle possédant également un impact so Afrique de l’Ouest. Exemple 40 : Projets issus de portfolios ou de

programmes

Un projet a un cycle de vie constitué de plusieurs phases Chaque projet comporte un cycle de vie, qui n’est autre que l’ensemble des phases qui le compose. C’est le cadre de référence, un cadre auquel le management de projet doit toujours se référer. Le travail lié à la construction réelle des livrables du projet est accompli à travers ces différentes phases. Le travail détaillé d’élaboration des livrables s’appelle « le cycle de vie ».

Le cycle de vie d’u séquentiel des phases sont déterminés en fo

l’organisation ou les projet. La documentat sur une méthodologie Définition 7 : Cycle de vie d'un projet

Dans toute organisation, même dans celles ne disposant pas de méthodologie propre pour manager un projet, que ce projet soit simple ou complexe, son cycle de vie possède toujours les caractéristiques suivantes : 1. Démarrage du projet ; 2. Organisation et préparation ; 3. Exécution du travail du projet ; 4. Clôture du projet.

Figure 13 : Projet à phase unique : en cascade

La durée des phases dépend du projet. Différentes durées de phases sur différents projets Viaduc de Millau : ce projet a connu 13 années de phase de préparation, d'études techniques et financières et 3 années de phase d’exécution du chantier. (Source : Wikipédia). Stade de France : L’une des caractéristiques de ce chantier fut sa rapidité d’exécution. Les 800 000 m² de terrassement ont été effectués en 5 mois et les 180 000 m³ de béton coulés en un an. Les aménagements techniques, la pose du toit, l’installation de la tribune mobile de 25 000 places se sont également

effectués en un an. (Source : Wikipédia). Exemple 41 : Différentes durées de phases sur différents projets

Chaque projet est unique et comporte des activités comme des livrables distincts. Mais quels que soient les processus de management de projet que l’on utilise, les caractéristiques du cycle de vie de projets ne vont pas changer. Même face à un projet réduit, on passe toujours par ce cycle, même si certaines phases ne sont qu'un exercice mental. Ce qui change d’une organisation à l’autre, c’est la manière de traiter chacune des phases et le passage d’une phase à l’autre. Quand on ne dispose pas de

méthodologie, on traite les travaux de manière hasardeuse, en tentant ceci ou cela, en se souvenant soudain d’avoir oublié un élément, et ainsi de suite. Dans un cadre où il manque une méthodologie, on agit aussi de façon réactive : à chaque situation nouvelle, on se contente de réagir. L’idéal est de fonctionner de manière proactive et structurée. Les sections suivantes vont permettre cela.

Un projet peut être managé par phase et par étape Nous avons déjà abordé le fait qu’un projet est constitué de plusieurs phases. Il faut également savoir que les objectifs de chacune de ces phases peuvent être atteints en plusieurs étapes,

abordée l’une après l’autre, tout comme le suggère Robert G. Cooper dans son livre Winning at New Products, paru aux éditions Addison-Wesley. On peut également poser la condition suivante : pour passer d’une étape à la suivante, il faut franchir la porte d’étape, comme illustré dans l’exemple ci-dessous.

Exemple 42 : Porte d’étape vs phase

La porte d’étape (stage gate) Cette porte d’étape peut être vue comme un « checkpoint » obligatoire par lequel

le projet doit passer pour parvenir à l’étape suivante. C’est le point de contrôle qui sert à vérifier à la fois si les objectifs de l’étape sont atteints et s’il est toujours utile de continuer le projet et de passer à l’épreuve suivante. En effet, si l’objectif du projet n’est plus aligné avec ceux de l’organisation et donc que le projet n’est plus utile pour le business, ou bien si l’on se rend compte qu’il n’est plus en mesure de livrer le ROI attendu, autant arrêter et fermer définitivement la porte menant à la prochaine étape. Il n’est en effet pas recommandé d’attendre la fin du projet pour se rendre compte qu’il n’est plus utile de le poursuivre. Cela représenterait des dépenses inutiles. À

chaque porte d’étape, on analyse donc les métriques (coûts, délai, scope, qualité, etc.) du projet et on se propulse vers les étapes restantes pour voir si, en tenant en comptes des métriques actuels, les objectifs de ces étapes, et donc du projet, peuvent toujours être atteints. Dans le cas contraire, on apporte les ajustements nécessaires : cela s’appelle faire du management de projet. Pour ce faire, il faut de la méthodologie et c’est l’objectif de la section suivante.

Section 3 Besoin de Méthodologie

Méthodologie : E techniques d'un d Système de pratiques de règles utilisées par discipline (PMBOK® Définition 8 : Méthodologie

La seule méthodologie qui vaille est celle qui fonctionne, celle qui donne des résultats, aussi laborieuses que puissent

être les actions entreprises. Alors, pourquoi un Manager de Projet, ayant toujours mené à bien ses projets sans suivre de méthodologie particulière, devrait-il changer du jour au lendemain ? Ce Manager de Projets dont les techniques, la manière de procéder ont fait leurs preuves durant des années, pourquoi devrait-il changer ? Par esprit d’ouverture aux pratiques de qualité qui ont démontré leur efficacité, par envie d’élargir ses horizons vers les méthodologies de standard internationales et surtout, sans montrer de suffisance dans le fait de penser déjà tout savoir, par curiosité d’apprendre et de se tenir au courant des idées existantes comme des nouveautés.

Notons encore que l’individu familier d’une méthodologie reconnue détient l’avantage de s’intégrer dans n’importe quelle organisation usant de la même méthodologie. Par ailleurs, la compétence en management de projet étant transférable, l’individu concerné peut passer d’un secteur d’industrie à un autre. Ces différents atouts offrent la possibilité d’une mobilité internationale en travaillant sur des projets de tout type et de tout secteur en faisant appel à une même méthodologie. « L’homme intelligent apprend par sa propre expérience. Le sage apprend par l’expérience des autres.

L’ignorant, lui, n'apprend jamais. » Confucius Par méthodologie, il faut entendre la manière de manager le projet, celle-ci incluant l’organisation et les pratiques mises en place.

Pourquoi ce besoin d’adopter une méthodologie standard ? Comment évaluer la maturité du management de projet au sein de votre organisation ? Les projets sont-ils managés proprement ? Existe-t-il des plans de projet, une charte de projet, des rapports mensuels sur l’état d’avancement du projet ? Ces derniers sont-ils communiqués verbalement ou

via des templates ? Les projets sont-ils suivis par une personne habilitée, par un team leader procédant de façon ad hoc ? Cette personne possède-t-elle les qualifications nécessaires ou se voit-elle assignée à ces tâches ponctuellement ? Démarre-t-on les projets de façon formelle ? Ce sont autant de questions qu’il faut se poser. Afin de démontrer la nécessité d’une méthodologie au sein d’une organisation, il suffit de répertorier l’ensemble des projets effectués dans le passé et d’étudier de quelle manière et dans quelles conditions ils ont été livrés. Les faits ci-dessous sont-ils familiers à votre organisation ?

1) La plupart des projets sont terminés tardivement et dépassent souvent les budgets impartis ; 2) Le résultat du projet ne répond pas aux exigences de fonctionnalité imposées par le client ; 3) On a l’impression de réinventer la roue à chaque fois que l’on démarre un projet ; 4) On a l’impression que l’on découvre pour la première fois les produits que l’on livre à chaque projet ; 5) Les techniques et les processus préconisés par le Manager de Projet ne sont pas appropriés et nécessitent d’être adaptés pour chaque projet ;

6) L’organisation pense que le processus de management de projet est une affaire de compétence relevant du Manager de Projet ; 7) Dans votre organisation, dès que l’on évoque de meilleures pratiques et des modèles, nombre de managers pensent immédiatement à surplus de travail, retards et "paperasserie" ; 8) Les outils et templates sont à créer pour chaque projet. Votre organisation pense que le management de projet est un logiciel - lorsque vous discutez de management de projet avec certains managers, ces derniers imaginent, de prime abord, que vous envisagez

d’installer un logiciel vous permettant d’améliorer votre compétence en tant que Manager de Projet ; 9) Il n’a pas semblé évident à ceux qui ont monté le projet, de prendre en compte dans l’échéancier et dans le budget, le temps nécessaire pour le gérer efficacement ; 10) Les projets aboutissent quand même malgré l’absence de planification et de management propres du projet, au prix d'un stress important et d’heures supplémentaires consenties durant le cycle de vie. Je pourrais citer ici nombre de

compagnies dont les points mentionnés ci-dessus font partie du quotidien, mais je crains pour ma carrière en m’y risquant. Je n’aimerais pas subir le même sort réservé à Zoé Shepard, l’auteure d’Absolument débordée ou Comment faire 35 heures en un mois

(Albin Michel), qui été sanctionnée par 10 mois d'exclusion de son poste dont elle avait tenu la chronique acide dans son livre. Certaines entreprises se sont fait la réputation d’être constamment en mesure de manager efficacement leurs projets. Mais la plupart d’entre elles ne jouissent pas d'une telle renommée. Les années se suivent et se ressemblent pour certaines organisations ; chaque projet leur vaut

une découverte car, aucune leçon, aucun enseignement ne sont tirés des projets précédemment effectués. On s’attelle également aux projets de façon laborieuse, sans aucunement s’y impliquer, non parce que cela demande un investissement non désiré en temps et en effort, mais parce que les leaders préfèrent jouer les politiques pour conserver leurs postes et positions au sein de l’organisation. Il est difficile d’être un bon Manager de Projet dans une entreprise qui n’accorde pas d’importance aux compétences en matière de management. Par exemple, si vous consacrez du temps à définir correctement le projet et que le client vous demande par la suite pourquoi vous

yavez consacré tant de temps, vous ne serez sans doute plus très enthousiaste quant à planifier votre prochain projet. Pour demeurer efficace, toute entreprise doit promouvoir un processus commun de management de projet. Avant de rentrer dans le vif du sujet sur les méthodologies qui fonctionnent, le lecteur peut juger de la différence entre méthodologies avec l’exemple ci-après: Pôle Sud : même projet pour un monde de différence dans les deux méthodologies utilisées (Source : Wikipedia) Le projet consiste à devenir les premiers hommes à atteindre le Pôle Sud géographique. Il existait une rivalité légendaire au

dénouement tragique, l’une des plus mémorables de tout le XXe siècle, entre le Norvégien Roald Amundsen et le Britannique Robert Falcon Scott. On sait que l’expédition conduite par Roald Amundsen fut une grande réussite alors que celle menée par Scott se solda tragiquement par la mort des membres de l’équipage sur le chemin du retour. Les raisons du succès d’Amundsen et de l’échec de Scott ont toujours été un sujet de controverse et de discussion, mais une chose est certaine, ils avaient tous deux des approches différentes. Méthodologie de l’expédition britannique Terra Nova conduite par Robert Scott Scott, qui préparait une expédition fondée sur les notes et les cartes d'une route défrichée par son ex-lieutenant,

hâte ses préparatifs, négligeant ses calculs de vitesse, de distance et de consommation de rations. Seize hommes entameront le voyage en utilisant des véhicules chenillés, des chiens – qui rejoindront bientôt le camp de base – et des poneys qui finiront abattus pour servir de nourriture. Trois groupes de douze hommes poursuivirent ensuite l’ascension du glacier, hissant et tirant eux-mêmes leur matériel. Un seul d’entre eux tentera la conquête du Pôle, les deux autres se voyant renvoyés au fur et à mesure selon les latitudes atteintes, la composition de l’équipe polaire étant décidée par Scott au cours-même du voyage. L'erreur de Scott dans cette expédition fut sans conteste d'avoir ignoré, à l'inverse de Roald Amundsen,

l'apport prépondérant des chiens de traîneaux groenlandais dont la résistance, la force de traction et la rapidité assurèrent le succès du Norvégien. Il avait opté pour des poneys qu'il fallut abattre rapidement, le contraignant alors à poursuivre sa route en utilisant la seule traction humaine. Il disait que ces conditions rendraient sa victoire plus humaine et plus noblement accomplie, mais cette conception lui aura finalement coûté très cher. Bien qu’il ait atteint le Pôle Sud un mois plus tard après Amundsen, il n’a jamais planifié son retour. Hagards d'épuisement et sans chiens pour flairer leurs précédentes traces, les membres de l’expédition perdirent un temps précieux alors que l'hiver approchait inexorablement. Ils finirent par mourir

de froid et de faim avant d’avoir pu rejoindre la côte du continent. Méthodologie de l’expédition norvégienne conduite par Roald Amundsen Le succès de l'expédition d'Amundsen tint à une préparation soignée, des équipements de bonne qualité, des vêtements appropriés (en peau animale), une tâche principale simple (Amundsen ne fit pas de relevés pendant le voyage au Pôle et ne prit que deux photos), une bonne connaissance des chiens d'attelage et l'usage effectif des skis. En contraste avec l'expédition de Scott, celle d'Amundsen est sans surprise et bien planifiée, aussi bien pour l’aller que pour le retour. Amundsen et ses

hommes s’étaient préparés pour le voyage au Pôle. Ils amélioraient leur matériel, particulièrement les traîneaux. Ces traîneaux étaient du même modèle et fabricant que ceux de Scott et pesaient 75 kg chacun. L’équipe d’Amundsen réussit à diminuer leur poids jusqu'à 22 kg. Les tentes et les bottes furent également améliorées. Utilisant des skis et des chiens d'attelage, Amundsen et son équipage créèrent des dépôts de ravitaillement en ligne droite vers le Pôle Sud. Ils emmenèrent quatre traîneaux et 52 chiens (ils prévoyaient d’abattre quelques chiens au retour en vue de nourrir les hommes et l’attelage). Utilisant une route jusqu'alors inconnue, ils parvinrent au plateau polaire suite à une ascension de quatre

jours. Le 14 décembre 1911 à quinze heures, ils atteignirent le Pôle Sud. Scott en était alors encore distant de 572 km. Conclusion Pour un projet identique, même pour deux managers de projet aussi expérimentés soient-ils, tout est dans la méthodologie. Une erreur dans l’approche et c’est le résultat final qui en pâtit. Quand un critique acerbe demanda à Amundsen s'il n'avait pas eu tout simplement de la chance alors qu'elle avait manqué à Scott, Amundsen répondit : « La victoire sourit à ceux qui ont pris les dispositions nécessaires, on appelle cela la chance, la défaite attend ceux qui n'ont pas pris les précautions

nécessaires, on malchance ».

nomme

cela

la

Exemple 43 : Même projet mené par deux personnes aux méthodologies distinctes

Dans un monde sans méthodologie, chaque Manager de Projet est une île qui possède sa propre approche du management. Certains réussissent, d’autres s’en sortent, et enfin, quelques uns échouent. Mais on se rend vite compte que plus un projet est important et complexe, plus il devient impossible de faire du management de projet au flair, au feeling et au petit bonheur la chance, aussi expérimenté que soit le manager du projet : une méthodologie est donc primordiale. Des difficultés peuvent être surmontées

à l’aide de méthodologies de management efficaces et de processus bien définis, que l’on peut répéter et qui ont fait leurs preuves. Cela ne veut pas dire qu’une organisation avec un PMO et une gouvernance forte garantisse forcément la réussite d’un projet, car il arrive que la lourdeur des processus le ralentisse et provoque un retard, mais cela augmente seulement sa chance de réussite.

Les organisations standardisent leurs méthodologies Nombre d’organisations standardisent leurs méthodologies de management de projet. Dans le monde ultra-compétitif

d’aujourd’hui, même les entreprises les plus traditionnelles reconnaissent la nécessité d’adopter une méthodologie – qu’elle soit développée en interne ou basée sur la pratique du marché (PMI, Prince2, CMMI, Six Sigma, SCRUM, Agile, etc.) – dans le cadre du management de projet. L’adoption d’une méthodologie augmente non seulement la la productivité, mais elle est surtout le seul moyen de survie d’une entreprise. La réalisation d’un projet peut, en recourant non à une méthodologie de management de projet mais à l’expérience du manager, aboutir à un succès. Les pyramides d’Égypte ont-

elles été construites suivant une méthodologie ou sur base de l’expérience et surtout du génie d’Imhotep? Cette expérience permet de faire face aux événements inattendus et susceptibles d’entraver la réussite du projet. Toutefois, il faut mettre un bémol à cette approche : lorsque le projet dépasse une certaine ampleur, en dépit d’excellentes capacités, aussi importantes soient-elles, le Manager de Projet n’est plus dans la possibilité de contrôler seul le projet et l’on court forcément au fiasco si une méthodologie n’est pas mise en place. Si l’on avait usé d’une méthodologie à l’époque des pharaons, on aurait peut-être construit les pyramides en un rien de temps, à

moindre coût et en évitant tant de pertes humaines. Bien planifiée et documentée, la réalisation de ce projet n’aurait surtout plus constitué le mystère qui est parvenu jusqu’à nous aujourd’hui. L’application d’une méthodologie, même suivie à la lettre, n’offre aucune garantie de succès par la seule vertu de sa norme ou de sa réputation, mais augmente considérablement les chances de réussite d’un projet. D’ailleurs, les connaissances décrites dans le guide ne doivent pas toujours être appliquées de manière uniforme pour tous les projets. Il est de la responsabilité de chaque organisation de déterminer la méthodologie la mieux adaptée pour ses

types d’activités et de projets. De même, c’est à chaque équipe de management de déterminer l’approche spécifique à adopter pour chaque projet, par rapport à cette méthodologie définie. Souvenezvous, tout projet est unique. Ce qui est précieux, dans la standardisation d’une méthodologie commune de management de projet au sein d’une organisation, c’est que le même processus peut servir pour tous les projets. On peut les répéter. Il faut dépasser les préjugés sur l’efficacité illusoire des méthodologies et le retard qu’engendrent leurs applications. Certes, la bonne méthodologie est celle qui a fait ses preuves et qui fonctionne, mais doit-on répéter des actions fastidieuses parce

qu’elles donnent des résultats ? Ne fautil pas plutôt les éviter parce qu’elles sont laborieuses ? Les formules gagnantes pour un projet peuvent ne plus l’être pour le prochain, mais les processus, techniques et outils – composants d’une méthodologie – peuvent rester les mêmes.

Projet réussi grâce à méthodologie Scope du projet : construire une cen dans un désert isolé pour supporter les Newmont au Nevada. (Source : P Novembre 2009) Ce projet au budget de 533 millions convoité, décerné par PMI®, du meil grâce à l’application efficace d’une mét Ils ont livré le projet 10 mois à l’avance le cyclone Katrina qui n’était pas pré

initiaux et qui aurait pu générer des c l’écosystème du projet s’en est trouvé rares car elles étaient affectées en prior reconstruction de la ville dévastée par l millions d’heures ont été prestées sans aurait pu tout retarder. Depuis son ex accompli plus de 99% de disponibilité exigences du contrat. Et la cerise sur le de dollars US ont été économisés en observée dans les revenus. Pensez-vo ou à la simple expérience du Manager Projet et son équipe se sont tout rigoureusement les fondamentaux du m qualité, performance - et avaient mis nécessaires. Selon les acteurs de ce p management de projet valorisant les rela Exemple 44 : Projet réussi grâce à l’application efficace d’une méthodologie

Il faut savoir qu’en début de projet,

lors de la phase de démarrage, tout arrive de façon chaotique et frénétique et c’est le Manager de Projet qui introduit de la structure et de l’ordre au projet en imposant sa méthode. Soit sa méthode lui est propre et basée sur son expérience, soit elle est issue de bonnes pratiques. Bien sûr, dans les deux cas, la présence d’une méthodologie ne garantit pas le succès du projet, la meilleure d’entre elles étant d’ailleurs celle qui a fonctionné et qui a rencontré du succès. Mais, en suivant les bonnes pratiques du métier déjà éprouvées, on adjoint un facteur chance supplémentaire à la probabilité de réussite du projet. Un succès est un effort, il n’arrive pas par hasard, il faut être structuré, coordonné

et pouvoir adapter une méthodologie de base efficace au projet visé. Une méthodologie offre un cadre formel structuré et organisé. Un management de projet efficace est essentiel pour le succès d’un projet. Disposer d’une méthodologie augmente la chance de réussite du projet. L’élaboration sur mesure d’une méthodologie revient au Manager de Projet. Une compétence à acquérir est la capacité à manager l’équilibre entre les méthodologies et leur application dans la vie réelle. Mettre en œuvre l’ensemble des processus et suivre à la lettre le contenu d’une méthodologie ne peut que ralentir, voire suspendre le projet et compliquer considérablement

la vie du Manager de Projet. Celui-ci doit au contraire faire preuve de pragmatisme, de souplesse et pourra alors tout aussi bien manager un projet avec une feuille de papier tout en suivant la méthodologie. Le pragmatisme et la simplicité sont les maîtres mots d’un sain management, à l’image du principe du KISS (Keep It Simple Stupid) prônant une simplification telle que les choses en deviennent limpides et accessibles même aux plus niais. Je n’ai jamais rencontré d’organisation suivant les processus, techniques et outils à 100% : la méthodologie sert plutôt de cadre pour aider le Manager de Projet à livrer les projets de façon efficace, idéalement selon une approche pragmatique et

flexible. L’objectif de cet ouvrage est de montrer comment l’on peut appliquer la méthodologie proposée par PMI® dans le PMBOK®, qui n’est autre qu’un guide de bonnes pratiques du management de projet.

Une méthodologie à l’image de l’organisation "La victoire sourit à ceux qui ont pris les dispositions nécessaires, on appelle cela la chance, la défaite attend ceux qui n'ont pas pris les précautions nécessaires, on nomme cela la malchance". Roald Amundsen

Certaines organisations pensent être dotées de méthodologies de management de projet parce qu’elles ont envoyé du personnel en formation mais, bien que celui-ci lui revienne en arborant fièrement de beaux certificats, elles continuent pourtant de procéder comme auparavant. Il y va de la responsabilité propre de chaque entreprise de déterminer la méthodologie la plus adéquate quant à ses activités et projets et cela ne se limite pas à envoyer ses employés en formation de management de projet, quoique ce soit déjà un bon début. Deux approches coexistent pour mettre en place une méthodologie de

management de projet: Élaborer sa propre méthodologie : personne d’autre que l’organisation ne peut comprendre aussi bien les types de projets que la structure déjà en place, ainsi, il lui est plus facile de créer une méthodologie sur mesure qui reflète parfaitement sa philosophie et ses pratiques. Les organisations peuvent adapter les bonnes pratiques du marché, ou les imiter, voire les améliorer - chose néanmoins ardue. De nombreuses entreprises procèdent actuellement de cette façon. Acheter une méthodologie : en

élaborant sa propre méthodologie, l’organisation peut être surprise d’apprendre qu’elle ressemble finalement à la plupart de ces bonnes pratiques dont les gens usent, car on aura toujours besoin de planifier, d’intégrer un échéancier du projet, de gérer le contenu et les risques, de communiquer, etc. Ainsi, l’achat d’une licence permettant l'utilisation d’une méthodologie préexistante et éprouvée peut faire gagner du temps à l’organisation : il lui suffira tout simplement de la personnaliser pour qu’elle s’adapte à ses activités et ses types de projet. En général, les méthodologies pré-élaborées contiennent déjà tout ce qu’il faut

pour une organisation réussie.

Figure 14: Méthodologie customisée à l'image de l'organisation

De toute façon, peu importe qui invente la méthodologie, l’important est d’être en situation de la mettre en œuvre au sein de l’organisation. Il ne faut jamais perdre de vue que la méthodologie doit être à l’image de l’organisation, et surtout pas l’inverse : ce n’est pas parce que les managers de projet s’affichent fièrement avec leur certification professionnelle et qu’ils clament pratiquer efficacement le management que tout le monde se pliera à leur méthodologie. Pour certaines compagnies, qui démontrent un manque

évident de culture en ce domaine, le management de projet n’est rien de moins que la manière d’expédier les projets dans les temps et le budget impartis.

La justification d’une méthodologie La bonne pratique existe mais elle n’est pas suffisante. Chaque compagnie et organisation doit pouvoir élaborer la sienne en fonction de ses attentes et de ses besoins propres. Pour ce faire, une organisation devra être capable de customiser une méthodologie en fonction des types de projet qu’elle entreprend, en les classifiant soit par la taille (ce qui a été vu en section 1), soit en fonction

des exigences du projet et de la technologie nécessaire à sa réalisation, comme expliqué par la figure cidessous.

Figure 15: Choix de la méthodologie en fonction des exigences et de la technologie

On peut dénombrer au moins quatre types de méthodologie : Méthodologie pour un projet simple : Quand les exigences sont connues presque à 100% et que le Business Case est clair pour tout le monde, avec uniquement un léger délai entre l’investissement et le retour (ROI) et que par-dessus tout la technologie pour réaliser le projet est claire et certaine, alors le projet est simple et on est dans un mode de management de projet classique. Même une organisation non dotée d’une méthodologie propre de management peut réussir ce type de projet. Quoiqu’ il y en ait qui

trouvent encore le moyen d’échouer... Une version « light » customisée des méthodologies comme PMI®, Prince 2® est par exemple appropriée pour ce type de projet.

Figure 16: Projet simple : Exigences claires et connues

Méthodologie pour un projet compliqué : Nous nous trouvons ici

dans une configuration où les exigences sont connues et claires jusqu’à un certain point, disons autour de 80%, et où le Business Case est encore sujet à l’évaluation des experts. Il peut également exister un délai pour le ROI. Nous sommes aussi dans un cas où la technologie pour réaliser le projet n’est pas claire ou certaine, dans le développement ou la construction par exemple. Ici, un travail en collaboration avec le client et les utilisateurs finaux est utile pour déterminer et finaliser le résultat du projet en affinant les exigences. Une version « full » customisée des

méthodologies comme PMI®, Prince 2® est par exemple appropriée pour ce type de projet.

Figure 17: Projet complexe - Exigences presque

connues et claires

Méthodologie pour un projet complexe: Dans ce cas de figure, les exigences sont très peu connues en début de projet, peut-être jusqu’à 20%, et le Business case est seulement spéculatif, tandis que l’investissement est incrémental sans avoir un ordre de grandeur sur le ROI. Nous sommes également dans le cas où la technologie n’est pas certaine et où il faut peut-être changer d’architecture, par exemple. Il s’agit donc d’un projet typique d’innovation où on s’attend à obtenir comme résultat une rupture technologique (breakthrough). Les

stratégies à suivre ne sont pas bien définies dans ce cas car on spécule même sur les objectifs du projet. La méthodologie Agile, ou ses processus comme le SCRUM pour le développement des logiciels, est appropriée pour ce type de projet.

Figure 18: Projet complexe - Exigences très peu connues et pas claires

Méthodologie pour un projet chaotique où règne l’anarchie : Ici, tous les stakeholders sont en conflit ouvert sur les exigences du projet, le Business case et l’architecture, loin d’être clairs et acceptés par tout le monde. Cette relation conflictuelle rend le projet chaotique car une anarchie s’installe. Certains s’interrogent sur les investissements colossaux faits en amont pour lesquels il n’y a pas de retour visible, tandis que d’autres se posent des questions concernant les raisons pour lesquelles le Business lance ce projet, etc. Dans ce cas, l’organisation a besoin de revoir

toute son approche dans la sélection d’un nouveau projet avant de définir la méthodologie à adopter pour le management du projet. Il s’agira alors forcément de l’une des trois méthodologies citées ci-dessus. Chaque organisation devrait pouvoir évaluer le niveau de maturité de management de projet en son sein et commencer à implémenter cette méthode au bon endroit. Ne pas trop en faire, au début, sous peine de noyer l’organisation, mais procéder de façon graduelle. Pour certains, le management de projet coûte et ne génère que de la paperasse inutile, mais ils ne savent pas combien et c’est pourtant une question critique pour le business. Avoir une

méthodologie ne signifie pas disposer d’un assistant, d’une secrétaire, d’un leader technique pour manager le management de projet. Ce n’est pas parce qu’une personne est responsable d’expédier un projet que cette personne possède les qualifications requises pour le management de projet. Pour qu’une méthodologie fonctionne dans une entreprise, il faut qu’elle soit ancrée dans la culture de la compagnie et de chacun de ses employés, que ceuxci aient l’assurance de parler de la même chose en utilisant un vocabulaire commun, au niveau national comme international, qu’un project charter, un Risk Log ou un EVM soit compris de la même façon partout et dans un langage

accessible ; non comme ces posters aux termes complexes, affichés fièrement mais inutilement sur les murs pour montrer qu’une méthodologie existe au sein de la compagnie… L’information doit être comprise par tous, aussi bien par les consultants externes qui l’ont implémenté et qui ne sont plus présents dans la compagnie, que par les managers qui ont passé commande de la méthodologie. Enfin, cette démarche doit être stimulée par le management et la direction. Dans certaines entreprises, le démarrage du projet se fait toujours suite à la signature du project charter. Tout le monde dans l’organisation doit savoir ce qu’est un project charter. Tout le monde

doit avoir une connaissance des méthodologies de management de projet ou de programmes ou de portfolio. Il ne faut pas que des personnes de pays différents puissent penser que Beijing et Pékin sont deux villes distinctes.

Une méthodologie et un vocabulaire commun Les méthodologies offrent une terminologie commune normalisée. Un tel vocabulaire commun est un élément essentiel de n’importe quelle discipline professionnelle. Issu de la même méthodologie, il offre aux managers de projets comme à l’organisation entière l’assurance d’être compris, de ne pas se tromper de sujets, en évitant tout

malentendu. Il ne s’agit pas d’être un fanatique des jargons compliqués, inaccessibles à tous, mais simplement d’utiliser des jargons issus des bonnes pratiques utilisées et pratiquées par bon nombre d’entreprises. Un vocabulaire commun offre une communication plus claire pour toute l’organisation. Quand vous managez un projet où les parties prenantes sont éparpillées partout dans le monde et dont l’anglais est habituellement la première langue, voire la deuxième, il est impératif de pouvoir parler de la même chose : project charter, steering committee, méthode des Earned Value, etc. Pour certaines personnes, le mot planning signifie un fichier Gantt alors

que, pour d’autres, il comprend le scope, la durée, les échéanciers ou encore les limites du projet. Toutefois, ne vous en faites pas, cet ouvrage n’est pas rédigé dans un style jargonnant spécialisé, mais davantage dans un langage simple et compréhensible par une vaste audience, tout en utilisant les vocabulaires issus du PMBOK®. L’idée n’étant pas de saturer le lecteur avec des termes compliqués et sophistiqués mais d’illustrer l’essentiel des vocabulaires à maîtriser à travers des exemples. Quand les intéressés parlent des langues différentes, il vaut mieux utiliser des graphiques ou des dessins avec un

vocabulaire accessible à tous, qu’une liste à puces dans une langue que la majorité ne peut comprendre. Les entreprises qui standardisent ou industrialisent leur méthodologie de management de projets sont souvent des multinationales aux sites et à la clientèle internationaux, ce qui justifie l’usage d’un langage commun ; l'anglais étant (hélas) devenu le langage de référence dans la communication internationale.

Meilleure intégration de la méthodologie à travers les PMOs De plus en plus, on constate une explosion de façon significative, au sein

des organisations - et cela quel que soit le secteur d’industrie - de centres d’intelligence et de coordination de management de projet, dont l’objectif est de se concentrer sur les données tactiques des projets et que les entreprises utilisent comme arme stratégique dans le management de leurs portfolios de projets. Ces centres sont plus connus sous le nom d’offices de management de projet (PMO) ou encore bureaux de projets, dont nombre d’entreprises réalisent aujourd’hui les valeurs ajoutées et dont le rôle varie d'une organisation à l'autre. Mais, généralement, ce PMO n’est autre qu’une entité ou un groupe entier au sein d’une organisation dont l’objectif est de

standardiser et d’industrialiser les méthodologies de management de projets, en définissant et en maintenant les méthodologies, les pratiques et les processus ainsi que les outils et techniques de management de projets. Le PMO représente, aux yeux des managers de projet, ce que les tours de contrôle sont aux pilotes d’avions. Le PMO évite également les collisions entre projets, autorise le lancement d’un nouveau, guide le projet de sa phase initiale à sa phase de clôture, donne la priorité à un projet par rapport à un autre. Ces entités centralisées, vouées à l’amélioration des pratiques et des résultats des managers de projet, autorisent un contrôle du management de projet au niveau de

l’organisation au détriment d’un contrôle unilatéral par le Manager de Projet. Les PMO font la promotion de la valeur de la méthodologie en place et démontrent comment cette méthodologie peut se traduire en termes de succès du business. En ce sens, les PMOs, qui défendent les intérêts du business et ses différents aspects, sont le lieu indiqué pour les prises de décisions concernant les projets, dans l’intérêt supérieur du business, comme par exemple, l’activation du Kill Switch afin de suspendre un projet ne livrant plus la qualité attendue par le business. Les PMOs, qui influent globalement sur la mise en place d’une méthodologie

de management de projet et sur la mise en action des objectifs stratégiques d’une organisation, doivent se fonder sur les méthodologies les plus notoires et les plus pratiquées.

Le chapitre de PMI® et l’importance des réseaux de Manager de Projets « Toute relation est illusoire, mais on ne peut se passer d'autrui. Le monde extérieur vous donne continuellement l'occasion de vous voir et de vous observer, donc une chance de vous transformer. » Swami Prajnanpad

PMI® organise des congrès, séminaires et workshops partout dans le monde, mais ces événements sont surtout organisés par région grâce à la présence de ce qu’on appelle Chapitre, qui n’est autre que l’association des managers de projet ou de programme où tout échange d’information sur les méthodologies s’établit, où tout réseau se crée. En France par exemple, les chapitres PMI® sont présents dans la moitié nord, tandis que deux autres existent à l’ouest et dans le sud. Ces chapitres organisent également des conférences, répondent aux sollicitations des entreprises qui souhaitent connaître la méthodologie de management de projet proposée par PMI®, ses référentiels (standards) et ses

certifications. L’appartenance à un groupe ou l’identification à un groupe tel que ces chapitres peut donner des repères et représente également une force, surtout lorsque l’on se sent isolé avec ses idées au sein de sa propre entreprise. On peut rencontrer les membres de ces chapitres en face à face et parler de nos difficultés dans l’approche de tel ou tel autre problème dans un projet, ils sont toujours prêts à conseiller, à montrer la voie. Surtout si faire partie de l’un d’entre eux est tout ce dont vous rêvez, vous faire membre de ces chapitres ne peut que vous être bénéfique. L’adage ne dit-il pas que si vous fréquentez les winners, vous pouvez en être à votre

tour ? Discuter avec ses pairs de ses challenges au quotidien, de ses succès, des événements qui nous ont inspirés, peut être source d’inspiration et peut même créer des énergies positives pour la suite. Que l’on discute de notre vie personnelle ou professionnelle, d’un événement social, d’un livre ou d’un film, cette interaction sans la moindre arrière-pensée est toujours rafraîchissante et un pur plaisir. Particulièrement dans les moments difficiles, disposer de réseaux d’intérêts communs rend les choses plus tolérables. Vous verrez que le métier de Manager de Projet peut être très difficile parfois, surtout quand la pression est à son paroxysme. Pas besoin de coach,

vous reconnaîtrez, lors d’événements comme celui-là, ceux qui partagent vos valeurs, vos aspirations, votre humour et votre passion pour le management de projet. Les chapitres PMI® offrent un accès à l’information sur le management de projet, les méthodologies, on y échange des idées. Ces chapitres intègrent les usages et autres qui s’imposent et se pratiquent aujourd’hui dans la plupart des organisations au niveau des managements de projet. L’une des grandes richesses de ces moments est sans doute leur vibrante et permanente activité, animée par des personnalités aussi marquantes que surprenantes. Je retiens de ces rencontres des va-et-vient

incessants dans différents endroits, des conversations passionnées, une atmosphère d’ébullition intellectuelle autour du management de projet. Sans faire de démagogie ni de publicité, l’un des grands bénéfices d’être membre de ces chapitres est la possibilité de lier contact avec les autres managers de projet localement et globalement. Si vous souhaitez devenir Manager de Projet ou si vous l’êtes déjà ou si vous êtes une organisation à la recherche d’une méthodologie de management de projet, vous devriez apprécier la valeur de ces moments de connexion avec les autres, de création de réseaux, d’échange de bons procédés.

Section 4 Le Management de Projet On ne peut comprendre le management de projet si l’on ne comprend pas ce qu’est un projet. Nous venons de voir la section 2 l’essence, les sens et les raisons d’être des projets. L’esquimau dispose de 18 mots pour dire « neige », et nous n’en possédons

pas autant pour désigner le terme « projet ». Par contre, nous disposons de toutes les caractéristiques vues dans la section 2. Il est important de comprendre ces différentes caractéristiques si l’on veut maîtriser le management de projet. On ne peut non plus pas maîtriser le management de projet si l’on ne comprend pas la nécessité d’être organiser et d’utiliser une méthodologie. De fait, l’objectif de la section 3 était de démontrer qu’une méthodologie de management de projet offre une structure et augmente la chance de réussite du projet. Bien que rien ne vaille la pratique – commettre des erreurs de manière à en tirer davantage de leçons,

tout comme l’on n’apprend pas à nager dans les livres ou sur le bord de la piscine mais en se risquant immédiatement dans les eaux profondes – cette section tentera, en toute humilité, de traiter en profondeur, au travers d’exemples de techniques, d’outils et de processus de la science et de l’art du management d’un projet. Elle dévoilera les fondamentaux du management de projet, pouvant servir de socle sur lequel toute personne désireuse d’être Manager de Projet, ou l’étant déjà, peut s’appuyer au quotidien pour comprendre et pratiquer de façon efficace le management de projet. Cette section offre également divers exemples pouvant servir d’exercices à ceux qui préparent

leurs certifications de Professionnels du Management de Projet (PMP®). Enfin, tout un chacun peut faire usage de cette section comme boîte à outils, pense-bête dans le cadre de son travail ou de son apprentissage du management de projet au quotidien. Le management de projet n’est pas l’arcane d’une pseudo-science aux étranges terminologies et pratiques, c’est à la fois une science et un art. C’est tout d’abord une science dans la mesure où il repose sur des techniques et des processus éprouvés et réutilisables qui permettent de réaliser le projet avec succès. C’est un art ensuite, parce qu’il implique aussi de gérer et d’établir des relations avec des personnes et parce

qu’il exige du Manager de Projet d’adapter des compétences intuitives à des situations qui sont absolument spécifiques à chaque projet.

Le management de projet en général Si un projet correspond à un effort temporaire fourni pour créer un produit, un résultat ou un service unique, le management du projet n’est rien moins que la coordination des activités menant au résultat, produit ou service initialement défini en tenant compte d’un certain nombre de paramètres et de facteurs le tout orchestré par le Manager de Projet. Ce faisant, ce dernier doit pouvoir interconnecter les différentes

compétences et métiers devant intervenir sur les activités du projet. Le Manager de Projet doit également fédérer les différentes exigences des stakeholders qui peuvent influencer positivement ou négativement le projet.

Quand plusieurs personnes interviennent et concourent à la réalisation d’un même objectif, celui du projet, il est bon de laisser à une seule personne le soin de diriger et de coordonner chacune des activités des intervenants ou encore acteurs de projet. Cette personne est le Manager de Projet, au cas où certains lecteurs se poseraient encore la question à ce propos. C’est cette personne qui mettra en place la méthodologie appropriée pour livrer le projet duquel elle est responsable et ce en se basant sur la méthodologie inhérente à son organisation (si elle existe) ou sur sa propre expérience. Cette personne peut s’inspirer également

de l’approche ouvrage.

proposée

dans

cet

Manager de Projet l’entreprise réalisatri projet (PMBOK®). Définition 9 : Manager de Projet

En somme, il revient au Manager de Projet de faire tout ce qui est nécessaire pour mener à bien les efforts temporaires afin de réussir le projet, et cela en respectant l’éthique de la profession. En outre, le PMBOK® comporte une charte sur l’éthique que tout professionnel du management de projet certifié PMP® a le devoir de respecter. On a vu dans les sections précédentes qu’un projet réussi possède

un ROI positif et qu’il offre une grande satisfaction au client. On a vu également qu’un projet réussi est un projet qui répond – les surpassant même parfois – aux attentes des stakeholders qui, souvenez-vous, sont ces personnes ou groupes de personnes influençant positivement ou négativement le projet, mais dont la participation est importante. Ainsi, le management de projet consiste également à manager autant les attentes, de plus en plus grandes et parfois divergentes, des stakeholders - qui se montrent de moins de moins raisonnables au fur et à mesure que le projet avance -, que les contraintes des ressources allouées au projet.

Figure 19 : Les paramètres dynamiques d’un

projet

Ces contraintes peuvent se traduire par un budget qui paraît se réduire de plus en plus, une technologie qui change en permanence ou des fluctuations dans la communication avec tous les acteurs du projet. Il revient donc au Manager de Projet de jongler avec des facteurs et des paramètres qui évoluent tout au long du projet et de les prendre en compte dans la coordination des activités pour réaliser les objectifs du projet. Ces différents paramètres et facteurs sont interdépendants et dynamiques tout au long du projet. Aussi, une modification de l’un d’entre d’eux entraîne presque inévitablement un changement chez les

autres, la triple ou quadruple contrainte en étant la preuve.

Périmètres et Facteurs environnementaux Ces facteurs environnementaux peuvent être la limite de la technologie, le climat politique, la grève, la culture, l’infrastructure, le système d’information de l’organisation, les réglementations des organismes de normalisation et tout autre événement, contrainte ou dépendance pouvant influencer positivement ou négativement le management d’un projet. Les paramètres sont les coûts, le scope, le délai, la qualité, les ressources à la disposition du projet, les risques et

l’approvisionnement du projet.

Figure 20: Les Facteurs Environnementaux d’un projet

Sur les projets à dimension internationale, les stakeholders et

équipe projet sont souvent multidisciplinaires, multilingues et multiculturels. Le management de projet consiste donc à manager des ressources multidisciplinaires, multilingues. Le management de projet demande également de jongler et de tenir en compte de la différence de culture entre les stakeholders sur un projet international. Dans la culture européenne et américaine, on tend à respecter la date définie pour un deadline. En Asie, l’approche est différente, on est plutôt tenté de faire des concessions ici et là indépendamment de l’engagement pris.

Impact de la réforme des 35 he L’introduction de cette r ressources a eu un impa France. Plus le projet est grand, plus s En conséquence, lorsqu’un projet est d devient impossible sans une bonne l’exemple de l’implémentation du p d’hadrons) du CERN. Cet appareil particules le plus puissant au monde l’expérience scientifique la plus onéreu neuf milliards de dollars. On ne peu Manager de Projet en tenant compte de les ouvriers et certains ingénieurs frança moins que les quarante heures par se autres nationalités demeuraient elles au du temps de travail a certainement pro sur le délai et comme nous l’avons v Scope, Coût), cela aurait également de Dès lors, on ne peut qu’imaginer l’ historique. Le CERN a donc choisi

Management) pour la management de c Exemple 45: Facteur Environnemental

Dans certains pays, on n’apprécie pas d’être pris par surprise par des questions impromptues lors des réunions : le Manager de Projet doit donc veiller à envoyer les questions à l’avance. Quand les interlocuteurs sont de langues différentes, il faut utiliser des présentations, des dessins et user d’un vocabulaire simple compréhensible pour tous, d’où l’intérêt des méthodologies de standard international qui possèdent leur propre terminologie.

Management d’un projet de réalisatio mille pieds » en 1887 dont le Ma entrepreneur n’est autre que Gustave E Objectif : L'ambition d’une tour métalliqu

construire en centre-ville. (So

Facteurs et paramètres à pr Exigences des stakeholders et sur parties prenantes fut difficile. Le Mana le projet au maire de Barcelone où exposition universelle. Ce dernier refus surtout beaucoup trop onéreux ». Il diable, dépensant des fortunes en artic publiques pour trouver preneur. Finale universelle de 1889, il signa une conve financement et l'emplacement au centr Budget : Il avança de sa poche 80 8,5 millions de francs or. Les autorités vingt ans, à dater du 1er janvier 18 reviendra à la ville de Paris. La spécification et solution t d'innombrables problèmes techniq technologiques de l'époque. Les diffi rêve de tour hantait le paysage fantasm l'époque, sans succès. Puis, vint l'idée

s’inventaient à chaque étape de la également imaginer les ascenseurs hyd novateurs pour l’époque. Facteurs environnementaux : L suscita d'ardentes hostilités. Dès le protestation des artistes contre son édif remarquables de l’époque. « Méfionsdit alors Eiffel à ses contestataires. tendre non plus à en croire les quelque tour s'écroulera et tuera des milliers de sommet, les visiteurs seront asphyx s'enfoncera sous terre créant un véritab Ressources humaines : Le Manag l'avancement des travaux, dut cep retentissante des ouvriers du chanti conditions de travail risquées, une a n'avait plus qu'une idée en tête, accept (pour l'époque). Environ 250 ouvriers Délais : Le Manager de Projet res contrainte d’achever son projet avant

de 1889.

Résultats Si la déception est la différence né prenantes et la réalité, et si la satisfac l’exigence des parties prenantes et la r que le projet a été un succès à la gran des clients (visiteurs). L’objectif est a monde pour l’époque (1889), dont on technique et de la rapidité remarquable Retour sur investissement (ROI) : o mesure également à ce qu’offre en re projet. Moins de six mois après son in de deux millions de visiteurs, ce qui no seulement récupérer les coûts qu’il inv fit également fructifier. En tout cas, l’Histoire aujourd’hui.

Conclusion Eiffel a fait tout ce qui était en son pouvo

tenant compte des paramètres et facteurs En somme, il a accompli là du très bon m Exemple 46: Environnement et périmètres d’un projet à tenir en compte

La culture La culture est la façon dont les stakeholders et les membres de l’équipe projet voient et font les choses. Chacun a sa vision en fonction de sa propre culture. Cette dernière représente un ensemble partagé de valeurs et de croyances que tout Manager de Projet se doit de prendre en compte. La culture est ce qui est conscient et inconscient comme le montre la figure ci-dessous.

Figure 21: Iceberg de la culture

La culture possède donc la structure d’un iceberg : une partie visible et une partie invisible qui peuvent être plus ou moins faciles à reconnaître. Cependant,

il apparait que 90% de la culture est submergée. La culture est comme un filtre à partir duquel les gens interprètent la réalité et perçoivent leurs futurs. Elle représente en quelque sorte une façon cohérente et distinctive de la manière dont la personne concernée voit le monde. Tout Manager de Projet doit être capable de prendre en compte la culture, visible et invisible, de chacun des membres de l’équipe projet, ainsi que des stakeholders. Pour les Chinois par exemple, la relation importe beaucoup. Aussi, un échec dans l’un des aspects relationnels peut endommager l’entièreté des rapports. En Chine, tout Manager de

Projet doit donc tenir compte du « guan xi » ou « maintenance du réseau de relation », qui est intensément personnel, chaque individu ayant son propre « guan xi » et investissant du temps pour le développer et le maintenir. Cela donne au PM un avantage compétitif et une grande capacité à éviter les conflits, deux points très profitables pour le projet. Au Japon, les coûts, l’argent et les délais sont des sujets culturellement sensibles à aborder… Il y existe en effet le concept de « nemawashi » ou « pre-arrangements » qui exige que les problèmes soient résolus dans le cadre privé, afin d’éviter l’humiliation qui accompagne souvent les disputes

publiques. Pour le pays du soleil levant, le simple fait de prendre une décision est un échec, puisqu’elle devrait tout simplement faire surface naturellement. Or, Nemawashi rend les rapports transparents, sans surprises pour personne. Là, une approche des relations est à prendre en compte. Ainsi, la méthodologie choisie par le Manager de Projet doit tenir compte des idiosyncrasies des variétés de cultures que présentent les stakeholders et les membres de l’équipe projet. Le travail du Manager de Projet est de faire en sorte de réduire le fossé entre les cultures des stakeholders, mais aussi de s’assurer que chaque personne participant au projet contribue à cet

effort de compréhension. Chacun doit donc faire un pas vers l’autre afin de réduire ce fossé entre les différentes cultures.

Figure 22: chacun fait un pas vers l’autre pour combler le gap culturel

Nous pouvons donc comprendre aisément que sans une bonne méthodologie de management de projet et’un savoir-faire, le Manager de Projet

risque d’être vite débordé par les événements, surtout qu’en début de projet les informations tendent à fuser de toutes parts.

Le Management connaissances, de techniques aux acti les exigences. Ce nécessite le man approprié. (PMBOK Définition 10 : Management du projet

Désormais, cette définition du management de projet (Définition 10 : Management du projet) sera la référence fondamentale du management de projet dans cet ouvrage. Toute personne débutante considérera cette définition

comme acquise, comme un axiome. Et peut-être qu’un jour, elle élaborera ellemême sa propre définition du management d’un projet. La seule constante est le changement et rien ne dit que le management de projet d’aujourd’hui sera pareil demain.

Le management de projet est l’application des connaissances « Pour apprendre, il faut une attitude active et non passive. C’est en nous exerçant que nous nous perfectionnons. Pour assimiler ces principes, mettezles en actions, appliquez les chaque fois que l’occasion se présente. » Bernard Shaw

Le management de projet est l’application efficace de nos connaissances propres en la matière, comme le management des coûts, des risques, des ressources humaines et de la qualité par exemple. La science du management de projet proposée, la méthodologie PMI®, identifie neuf domaines de connaissance de management de projet que tout Manager de Projet doit être capable d’appliquer de façon efficace. Chaque domaine de connaissance est composé de processus, exécutés avec des outils et des techniques. Une bonne connaissance de chacun de ces domaines permet d’appliquer et de mettre en œuvre

efficacement les processus qui les composent.

Figure 23: Les 9 domaines de connaissances

définis dans le PMBoK®

Aujourd’hui, certains managers de projet se spécialisent à la manière des médecins qui se spécialisent de plus en plus dans un domaine comme la chirurgie, la radiologie, etc. délaissant la médecine générale. En plus de certification en PMP®, il existe aujourd’hui la certification PMI-RMP® qui atteste ceux qui veulent devenir Professionnels du Management des Risques et sont donc les spécialistes des connaissances sur les risques.

La dimension Business Toutefois, le Manager de Projet devrait ajouter à ces neuf domaines de

connaissances une bonne compréhension du Business. On a vu qu’un projet est créé dans le but de satisfaire les objectifs stratégiques du Business. En ce sens, un Manager de Projet qui a des connaissances et qui comprend les intérêts du Business et ses différents aspects possède un atout supplémentaire pour manager un projet, ce qui est également perçu comme un « plus » sur un CV. Le Manager de Projet qui comprend le Business peut élargir son champ d’action. Il est à même de prendre les bonnes décisions dans l’intérêt supérieur du Business et pas dans celui du projet. Il s’agira par exemple de tuer un projet en activant le Kill Switch quand celui-ci ne rapporte

plus la valeur attendue du Business. C’est aussi une façon d’élargir son champ d’action vers d’autres horizons plus larges et plus intéressants, plutôt que de se limiter au management du projet. La participation à l’élaboration du Business Case, ou encore à des sessions de planification stratégique du Business est également très gratifiante. Le respect d’une organisation vouée à un Manager de Projet impliqué au niveau du Business peut également s’accroître puisque vous fréquenterez les gens du Business et leur démontrerez tous les jours vos compétences. Et cela renforce l’attachement du Manager de Projet avec le Business, car il fait le lien entre le Business et les projets. Pour les

managers de projet ambitieux et qui font partie intégrante de la vie du Business, il n’est pas impossible de postuler à la fonction de CEO du groupe par la suite. Il n’est pas interdit de rêver. Jack Welsh n’a-t-il pas gravi tous les échelons en commençant comme ingénieur chez GE et en terminant sa carrière en tant que CEO ? Il est d’ailleurs reconnu comme l’un des dirigeants les plus emblématiques aux États-Unis durant la période 1980-2000.

Figure 24: Les Intérêts du Business d'abord

Management de l’intégration du projet

Ce domaine de connaissances force à

réfléchir concernant la colonne vertébrale du projet. Il lui offre un cadre, une formalisation et une reconnaissance officielle de l’existence du projet au sein de l’entreprise, ainsi l’autorisation formelle au Manager de Projet d’engager les ressources et le budget nécessaire. Cela recouvre les processus nécessaires pour s’assurer d’une bonne intégration de tous les éléments du projet.

Figure 25: Management de l'intégration du projet (Source : PMBoK®)

Elaborer la charte du projet Tout Manager de Projet doit

pouvoir initier un projet. Nous avons vu dans la section 1 que le démarrage de projet doit se faire suite à la signature d’un document officiel reconnaissant formellement le projet et autorisant le Manager de Projet à engager les ressources et à dépenser le budget alloué. Le point de départ de tout projet La première question qu’un Manager de Projet nouvellement assigné à un projet doit se poser est la suivante : « Pourquoi se donne-t-on la peine de développer ce projet ? » Ce projet n’est-il pas voué à l’échec ou ne présente-t-il pas un degré élevé de risque ? Quelles sont les parties

prenantes et qu’attendent-elles du projet ? Quels sont les risques ? Qui va financer ce projet ? Économisera-t-on de l’argent ou en rapportera-t-on ? Telles sont les questions à se poser lorsqu’on vous présente pour la première fois un projet, et cela avant même d’en évoquer le scope. La charte du projet devrait amplement répondre à toutes ces interrogations. Il faut une vision claire qui peut vous donner un sentiment de confiance. C’est ce qu’offre la charte du projet. Nul besoin de cent pages, cependant les informations critiques doivent être documentées et approuvées par tous les stakeholders.

Le PM qui vient de se voir confier la responsabilité d’un projet doit donc jeter un œil sur la charte du projet. S’il n’en existe pas, il revient alors au PM de la rédiger. La signature de cette charte de projet reconnait officiellement l’existence du projet et autorise le Manager de Projet à engager les ressources et à utiliser le budget alloué à ce projet.

Charte du projet sponsor du proje l’existence et donne d’affecter des r activités de ce proj Définition 11: Charte d'un projet

« Si la destination n’a pas été définie

au départ, il est difficile de dire que l’on est perdu.» Proverbe chinois Pourquoi ne faut-il jamais commencer un projet sans Charte de Projet signée ? Chaque organisation dispose de procédures pour autoriser le démarrage des projets. Celles qui utilisent une méthodologie à base de PMBoK® développent la charte du projet pour les raisons suivantes : Le pourquoi du projet : la charte de projet répond à la question « pourquoi l’organisation se donnet-elle la peine de réaliser ce

projet? » Existence du projet : la signature de ce document reconnait officiellement l’existence du projet au sein de l’organisation. Manager de Projet appointé officiellement : la signature de la charte de projet reconnait formellement le manager du projet et l’autorise à engager les ressources de l’organisation et à dépenser les budgets alloués aux projets. Support Financier et émotionnel des membres de la direction : la signature de la charte de projet par les cadres de la

direction offre la garantie de leur soutient au projet sur les plans financier et émotionnel. Ces exécutifs seront les premiers supporters du projet dans les moments difficiles, les négociations ou les conflits de haut niveau, puisqu’ils auront signé la charte. Il est crucial d’obtenir l’appui des cadres exécutifs tels que les directeurs de programmes ou viceprésidents du projet, voire présidents directeurs. Plus haut se situe le soutien, mieux cela sera pour le projet. Car ces personnes, en signant la charte de projet, s’engagent à tout mettre en œuvre

pour le mener à bien. Si la charte de projet n’a pas encore été élaborée à l’assignation du Manager de Projet, celui-ci se doit d’insister pour la développer et surtout la faire signer par le sponsor du projet, les personnes qui ont appointé le Manager de Projet et les membres des comités de direction, ou toute personne ayant une grande influence dans l’organisation quant au lancement et à l’arrêt d’un projet. Il pourra par exemple s’agir du président directeur général. Vous pouvez en effet être certain que la charte d’un projet signée par un tel individu ouvre les portes et facilite les relations, puisque personne ne veut le

décevoir. Mais si la charte du projet, ou tout autre document équivalent n’existe pas, faut-il se donner la peine de lancer tout de même le projet? Cela dépend de vous : un projet qui n’a aucun appui dans les hautes sphères, qui n’est pas reconnu officiellement et formellement dans l’organisation, vaut-il vraiment la peine? Chacun a ses idées sur le développement de sa carrière. Aussi, si vous êtes de ceux qui préfèrent simplement travailler sur n’importe quel projet, quelque qu’en soit l’issue, allez-y ! Mais si vous voulez un projet qui a de fortes chances d’être mené à terme, faites en sorte que ce document de charte de projet soit signé.

Soulignons encore une fois l’importance de la signature de la charte de projet Elle va permettre à tous les stakeholders, le steering committee et les membres du projet d’être à la même page concernant les objectifs du projet, ses exigences, les échéances, les risques, les gains, etc. C’est un accord passé avec les parties prenantes sur la vision du projet et la direction à prendre. C’est enfin synonyme de leur engagement sur le projet. J’ai vu trop de projets mourir faute de bonne connexion ou de bonnes personnes pour soutenir le projet dans les moments difficiles. La charte du projet est un outil

d’escalade pour le Manager de Projet à chaque fois qu’un stakeholder sort du cadre de l’accord. La signature de la charte de projet par les hauts responsables peut vous faire percevoir que vos intentions gagnent en puissance et en force. Vous allez vous sentir glorieusement invincible, visualiser le bon déroulement, la fin, le succès, car c’est un grand pas même si tout reste à faire. Avoir signé la charte du projet vous donne le sentiment que rien au monde ne peut entraver le succès de ce projet. Tout le monde a offert son soutien, son aide, les choses sont claires à l’avance. Toutes les conditions sont réunies pour mener le projet à bien.

Mais ne perdez pas la dynamique pour entamer la suite, savourez ce moment, cette émotion positive et pensez à la suite, autorisez vous à en vouloir plus. Contenu de la charte de projet La charte de projet ne doit pas être interminable, elle peut rester très « highlevel ». Ce document contient la solution aux problèmes pour lesquels le projet a été créé. Il doit donc reprendre les objectifs stratégiques de l’organisation pour lesquels le projet a été autorisé. Un bon document de charte de projet devrait contenir au moins ce qui suit: Historique: le contexte dans lequel le projet a été initialisé, en insistant sur l’existence d’un problème à

résoudre et d’un objectif stratégique à atteindre. Il doit expliquer l’obstacle que le Business cherche à surmonter en initiant ce projet. Exigences et bénéfices du Business et justifications de ces bénéfices : on peut se référer ici au business case (cas d’affaires). Cette partie démontre les besoins spécifiques du Business que ce projet adresse et surtout, les justifications des bénéfices (ROI) attendus en développant ce projet. Il s’agit de démontrer sur plusieurs années comment on va réduire les coûts et augmenter les revenus. Objectif du projet: nous devons

traduire ici les besoins du Business en une liste « high-level » contenant les objectifs du projet. Cette partie devrait offrir une bonne vision des objectifs que le projet doit réaliser et statuer sur la définition du succès du projet pour éviter toute ambigüité. Enfin, une bonne liste des objectifs du projet aide à déterminer la façon dont on va gérer le projet. Il faut inclure les facteurs critiques de succès du projet. Facteurs critiques de succès : il s’agit d’identifier les critères capables d’affecter le succès du projet. La conduite du changement, la

formation, la préparation intense, un pilote sont par exemple des critères de succès. Coûts: la liste des coûts aussi bien en CAPEX (les dépenses d’investissement du capital), qu’en OPEX (dépenses d’exploitation), en incluant les coûts de réalisation du projet ainsi que les coûts pour la partie opérationnelle et maintenance du projet. On fait appel ici au processus « estimer les coûts » des groupes de processus Planification. La technique d’estimation Top-Down avec un ordre de grandeur (ROM) de ±50% suffit à ce niveau.

Énoncé préliminaire du scope : il s'agit d'une brève description des livrables que le projet doit réaliser. Cette partie contient également les critères de succès de chaque livrable. La population impactée par le projet : dresser la liste des départements, des services, ou des équipes impactées par la réalisation de ce projet. Décrire de quelle façon ils seront touchés. Les processus impactés par le projet : rédiger la liste des

processus impactés par l’implémentation du scope du projet. Cette étape est très importante pour le management du changement, souvent mené par un autre Manager de Projet. Exigences fonctionnelles clés : dresser la liste des exigences fonctionnelles du projet. Une expansion de ces exigences peut provoquer un désastre sur le projet. Il faut se contenter de ce qui est absolument nécessaire et sans plus. Autres exigences : à ne pas oublier pour réaliser le projet :

Exigences en termes de logicielle et infrastructure Exigences en termes de déploiement Exigences en termes d’opérations, performance et support Exigences en termes de management de configuration Frontières du projet: délimiter à l’avance le projet et considérer les points suivants : Exclusions du scope: toujours mentionner noir sur blanc tout ce qui ne sera pas réalisé dans le scope du projet : les livrables, les

services ou produits, ou autres activités. Contraintes: documenter les contraintes organisationnelles, techniques, ou encore financières ayant une influence faste ou néfaste sur le projet. Spécifier les limitations dans lesquelles le projet doit opérer. Dépendance: documenter toute dépendance externe pouvant avoir une influence sur le scope, la qualité, le planning ou le budget du projet. Hypothèses: au début du projet, il existe très peu d’informations. Il faut donc faire

une série de suppositions. Dressez une liste des circonstances et événements qui doivent survenir pour que le travail soit un succès. Les hypothèses sont supposées vraies même si elles ne constituent pas des faits à 100%. La structure de gouvernance et organisation du projet : documenter la structure de gouvernance du projet, identifier le sponsor, nommer le Manager de Projet et les membres de l’équipe projet s’ils sont connus à ce stade. Il faut compléter cette partie par une liste de tous les

stakeholders, déterminés.

s’ils

sont

déjà

Risques Initiaux : dresser une liste des circonstances et événements qui pourraient affecter négativement le succès du projet. On fait appel ici au processus « Identifier » des groupes de processus Planification. Il faut associer ces risques avec une probabilité d'occurrence et un plan de mitigation afin de les éliminer, maitriser, transférer ou éviter. Macro-planning - Chronologie “high-level” de l’échéancier du projet : documenter la chronologie

des activités du projet, les dates de début et de fin. Nous avons toujours besoin de rapidité sur les projets, puisque le temps est l’ennemi de tout projet et qu’il faut réaliser rapidement les objectifs du projet afin d’accomplir ceux du Business. Plus vite on réalise le projet, plus vite on achèvera les objectifs du business. Un rythme lent peut tuer le projet. Compétences clés pour l’écriture de la charte de projet: négociation, communication Rédiger un tel document nécessite beaucoup de négociations. La charte de projet est le fruit de

discussions et d’arrangements sur le budget, le scope, les ressources et l’engagement des directeurs de projet ou encore des membres du comité de direction. La négociation est menée avec le sponsor du projet, les équipes techniques, le comité qui pilotera le projet, etc. En somme, avec les stakeholders. On a la carrière qu’on mérite. On choisit ses projets et le Manager de Projet peut juger à partir du document de la charte du projet s’il correspond à ses aspirations en termes de challenges et de carrière.

Élaborer le plan de management du projet

Tout Manager de Projet doit pouvoir élaborer un plan de management du projet, qui décrit la façon dont on compte manager les événements, prévus et imprévus, sur le projet. Ce document doit comprendre la manière donc on va gérer les livrables du projet, les coûts, les ressources, la qualité, les risques, etc. Afin de le rédiger au mieux, le Manager de Projet doit faire appel à son organisation : les systèmes d’information disponibles, les procédures en place s’il en existe (et les créer dans le cas contraire) et tenir compte des facteurs environnementaux de l’entreprise. Au besoin, le Manager de Projet peut faire appel aux jugements des experts métiers pour finaliser son

document. Ce plan de management du projet est la bible du projet et on doit pouvoir y puiser toutes les directives à suivre lors de l’exécution du projet. Si on ne sait pas quelle méthode adopter concernant le management des changements, il faut se tourner vers ce document. Si on ignore où archiver les livrables, ou si on ne sait pas comment gérer la qualité, c’est encore ce document que l’on doit consulter. Ce dossier est donc évidemment amené à être mis à jour tout au long du projet.

Plan de Management du Projet de To

Introduction : Le manag travers ses livrables. Ce do manager les livrables du projet, les prob

les risques, les ressources humaines, la de scope en cours de projet. Chaque dossier avant de commencer le projet qu’il ignore comment traiter d’un point

1. Plan de Management des livrables

Le plan de management des livrables a S’assurer que tous les livrables Définir les responsables de chaq Contrôler et surveiller l’état d’a S’assurer que les livrables seron S’assurer que les exigences p claires

Définition Un livrable est défini comme un résulta un élément qui doit être produit pour c projet.

Il y a 3 types de livrables : 1. Livrables sur papier : Busines

rapports d’état d’avancement d du projet, etc. 2. Livrables software : fichiers d scripts et les applications dével 3. Livrables hardware : les équ Gateway, Serveur de Communi

Processus Chaque membre de l’équipe proj pour enregistrer les détails et les descri est responsable. Il est requis d’entrer les Nom du livrable Description État d’avancement Date de début Date de fin Effort Les milestones liés à ce livrable Le Manager de Projet doit consolider

membres du projet un rapport d’état d’ ainsi du projet.

2. Plan

de Management Management)

des

Le plan de management de tous projet a pour les objectifs suivants : S’assurer que tous les problèm qu’ils ont été soumis à l’atte résolutions ont été adressées en te Utiliser un processus décisionn de l’équipe projet, concernant la r Fournir les moyens de concernant le projet ou l'équipe. Maintenir un fichier log (Issu décisions prises lors de la résolutio Offrir une grande visibilité d l'équipe projet. Enfin, s’assurer que tous les pr de réduire leur possible impact né

Définition

Problème : Tous les points, questions, qui empêchent le projet d’avancer et qu pas impacter négativement le projet. Fichier log de problèmes : Fichier dan résolution, est documenté. Indicateur de sévérité : Il faut détermi l’impact du problème: Vert : Pas d’impact encore sur la peut être résolu à temps. Jaune : Le problème peut ne pa avoir un impact sur le délai du pro Rouge : Le problème ne sera p impact sur le délai de livraison du Critère de sévérité : Il faut déterminer sur le projet : Critique : Le projet tout entier n’est pas résolu. Majeur : L’un des livrables maje

pas résolu. Medium : La non-résolution du le délai de livraison d’un livrable. Mineur : Le problème est à un doit tout de même procéder à sa d Processus Chaque membre de l’équipe doit suivre suivantes : 1. Identification du problème 2. Documentation du nouveau pr Log) avec le niveau de sévérité 3. Examen du problème (au choix 3.1. Affecter une ressource po 3.1.1. Investigation et 3.1.2. Examiner la solu 3.1.2.1. Valider l être un changement du 3.1.2.2. Rejeter l 3.1.2.2.1. (Retour

3.2. Escalader le problème ver 3.2.1.1. Recomm 3.3. Rejeter car ce n’est pas u 4. Implémentation de la solution 5. Fermeture du point dans le fich de l’équipe de la résolution

Figure 26:Processus de M

3.

Plan de Management du changem Le changement de scope peut survenir

une identification des modifications des toujours souhaitable car cela réduit changement de scope. Aussi, toute identifiée au plus tôt dans le but de réd délai du projet.

Définition Changement de scope : Il a lieu d’êtr effectuée sur l’une des dimensions du s Le budget attribué au projet Les livrables que le projet dev Les exigences du business et se exemple) Lorsque les spécificités techniq changé Le délai du projet ou le déla majeurs L’organisation : un changement l’organisation

Change Request Formulaire : Ce tout changement de scope. Les élément La description du changement s Une analyse de son impact su nombre de jours et du coût La date souhaitée et l’équipe qu

Processus Le formulaire de Change Request ainsi Log) sont les outils à utiliser pour l scope. Tout changement de scope doit dans ce fichier log. Chaque demande se sera faite pour l’implémenter ou le rejet 1. Identification du changement travers le formulaire de Project 2. Documentation du nouveau p Request log 3. Examen du problème (au choix 3.1. Affecter une ressource po 3.1.1. Investigation et

3.1.2. Examiner la solu 3.1.2.1. Valide être un changement du 3.1.2.2. Rejeter l 3.1.2.2.1. (retour 3.2. Escalader le problème ver 3.2.1.1. recomm 3.3. Rejeter car ce n’est pas u 4. Implémentation de la solution 5. Fermeture du point dans le fich 6. Informer l’équipe de la résoluti

Figure 27: Plan de Managem

4. Plan de management des Ressourc

Pour un management plus efficace d suivante doit être considérée : Travailler avec une petite équi sur le projet Organiser une réunion hebdom l’état d’avancement du projet, de susceptibles de survenir (Risques) Chacune des cinq personnes d’autres ressources sur le projet, dans l’équipe projet afin de limite

5. Plan de Management de la Comm

1. Réunion hebdomadaire avec les m

discuter des progrès, des problème 2. Réunion mensuelle avec le comité pour prendre des décisions conc l’état d’avancement du projet ain critiques.

3. Rapport mensuel dans lequel il co

- Les milestones atteints - Les milestones encore à at Les coûts engagés et une les objectifs du projet Approche des réunions

1. Assurez-vous que tous les partic 2. 3.

4. 5. 6.

l’agenda, l’heure de la réunion et Faites une liste de ce que chacun d Si la réunion nécessite une présen s’assurer que les projections sont pas perdre de temps lors de la ré outils multimédias. Les téléphones portables doivent ê Un fichier doit contenir tous les réunions. Les problèmes non-résolus doiven des problèmes (Issues Log).

Management de conflits 1. Les conflits devraient être consid 2.

3. 4. 5. 6. 7. 8.

développement. Il convient de toujours essayer besoins et les demandes de chacu de prendre une décision ou de for Choisissez un moment et un endr conflits et les explorer. Ecoutez ouvertement, sans opposi Répétez à votre interlocuteur demandez si c’est correct. Reconnaissez et admettez les argu Offrez votre point de vue sans pro exprimant sur un ton de reproche Cherchez à trouver un terrain d’en

6. Plan de Management de la Qualit

Pour des raisons de qualité assurance, adopté : Le projet sera effectué selon les Une ressource du départemen constituera l’unique point de cont Une ressource du départeme pour vérifier la conformité de la sécurité et d’architecture en vigue L’expérience de l’équipe projet

7. Plan de Management des Risques

Les risques seront identifiés et admi projet.

Activités Administration du fichier risque (Risks Log)

Tous les risques seront l’affaire toute l’équipe projet Tous les risques avec un impact critique seront passés en revue Tous les risques sont passés en revue

Identification Tous les membres de l’équipe projet so risques et à les transmettre au Manager dans le fichier log des risques (Risks Lo Evaluation et réponse aux risques Le Manager de Projet est responsable donc impliquer les ressources avec les l’impact des risques ainsi que des identifiés. Exemple 47: Plan de Management d'un projet

de ToIP

Diriger et piloter l’exécution d’un projet « Je hais ces cœurs pusillanimes qui à force de tout planifier n’osent rien entreprendre » Molière Le plus grand défaut des managers de projet est de se focaliser directement sur cette étape sans passer préalablement par celles de préparation. La phase d’exécution doit toujours être précédée des phases d’initiation et de

planification ; évidence qu’il faut souvent mentionner car son importance n’est pas reconnue par tout le monde. Même si vos managers vous mettent sous intense pression pour livrer le projet au plus tôt, il ne faut jamais sauter les étapes de préparation et d’initiation. Il ne faut jamais mettre la charrue avant les bœufs : rien ne sert de courir, il faut partir à point. Avec la direction et le pilotage de l’exécution du projet, on se situe dans le processus de réalisation des objectifs du projet, en fournissant chacun des livrables, avec les fonctionnalités et qualités telles que définies par les exigences du projet comme décrites dans le scope du projet.

Figure 28: Piloter et Diriger l’exécution du projet

C’est à force d’e-mails, d’appels téléphoniques, de réunions ou d’entretiens individuels avec les stakeholders et l’équipe de projet, et en s’appuyant sur le plan de management du projet que le Manager de Projet doit exécuter et diriger le projet en respectant les points suivants : la qualité définie des livrables ; l’éthique du métier car la fin ne justifie pas tous les moyens ; le délai imparti pour exécuter le projet en respectant l’échéancier, souvent appelé planning et les milestones définis auparavant durant la phase de préparation. Le

Manager de Projet doit se demander s’il est nécessaire d’appliquer la Loi de Parkinson qui consiste à utiliser l’entièreté du temps imparti à une tâche, même si le temps effectif passé à exécuter la tâche est moindre. Le Manager de Projet doit évaluer si son planning souffre du syndrome du calendrier qui consiste à attendre la date prévue pour démarrer une tâche, même critique ; le budget autorisé dans la charte de projet.

Planning (Échéancier du exécute et dirige son projet au préalable. Il doit influencer positiv

meilleur de son équipe pour exécute définies afin d’atteindre les objectifs du

Exemple 48 : Échéancier (planning) du projet ToIP

Durant ce processus, le Manager de Projet doit user de l’art du management de projet dans l’application de la

science du management des stakeholders et des ressources du projet. Ceci, en tirant le meilleur de son équipe, en tenant compte de la culture de chaque membre -car c’est à ce moment que l’on commence à former, à engager l’équipe projet, qu’elle soit composée de ressources internes ou des prestataires - et en organisant des réunions régulières avec elle. Par exemple, le Manager de Projet doit regarder si ses ressources ne sont pas victimes du syndrome de l’étudiant, qui consiste à ne démarrer son activité que la veille de la deadline définie pour fournir le livrable. Le Manager de Projet doit également gérer les stakeholders, afin que le projet satisfasse à leurs

attentes et qu’il bénéficie de leurs influences positives. Le Manager de Projet doit également prendre en compte la loi de Brooks dans le management de ses ressources, déterminant qu’un ajout de ressources sur un projet en retard accroît son retard. Le management du projet en période calme ne permet pas d’évaluer l’étendue des compétences du Manager de Projet. En revanche, en période de crise, en pleine tempête, on peut réellement apprécier si le Manager de Projet tient efficacement la barre. En effet, diriger et piloter l’exécution du projet revient aussi à faire du management en temps de crise des

ressources et des stakeholders, chacun contribuant à réaliser les objectifs du projet. Des problèmes surgissent lorsque l’une ou l’autre des ressources n’arrive pas à livrer sa partie, par manque de compétence ou à cause de malheureux concours de circonstances, indépendants de sa volonté ; ou encore, lorsque le projet ne satisfait pas aux attentes d’un ou plusieurs stakeholders. Pour ces raisons, durant l’exécution du projet, certains stakeholders ou membres de l’équipe projet auront ainsi détérioré l’ambiance et la confiance dans le projet ou l’équipe projet, d’autres encore les auront ruinés, tandis que certains auront travaillé à les rétablir et le Manager de Projet, plate-forme autour de laquelle

tout le monde doit graviter, se doit de rediriger les parties dans la bonne direction : celle qui permet la réalisation des objectifs du projet dans une atmosphère de confiance et de sereine collaboration. Le Manager de Projet doit se montrer bon leader en temps de crise, il doit pouvoir faire bouger les choses avec un vrai sens de l’urgence et de l’action. Le Manager de Projet doit user de la science de l’application efficace de ce processus, à l’aide des outils et de techniques que nous verrons de façon exhaustive plus tard, pour diriger et exécuter le projet jusqu’à ce que tous ses objectifs soient atteints.

Processus – Suivre et maîtriser le travail du projet Le Manager de Projet doit également suivre, contrôler et maîtriser ce qu’il a exécuté et dirigé et ce faisant, il doit mener des actions aussi bien préventives que correctives dès que cela s’avère nécessaire pour rester dans le périmètre du scope du projet. Ainsi, pendant toute la phase d’exécution du projet, le Manager de Projet doit constamment s’atteler à exécuter, à contrôler ensuite ce qu’il a exécuté et à intégrer dans la planification, les actions correctives et préventives, comme le montre la figure ci-dessous. Le Manager

de Projet doit se répéter continuellement « je planifie, j’exécute et je contrôle » et se remotiver sans cesse jusqu’à ce tout ce qui a été planifié soit exécuté. Pour ceux qui désirent approfondir le sujet, je conseille les ouvrages sur Deming et son cercle Plan-Do-CheckAct (PDCA). Certains managers de projet suivent et contrôlent leurs projets avec une seule feuille de papier A4 là ou d’autres nécessitent davantage de support.

Figure 29 : Cycle de planification Exécution - Contrôle et Suivi

Mais en général le Manager de Projet doit suivre ce qui est défini dans le plan de management du projet pour contrôler et gérer son projet au quotidien. Dans le cas de l’exemple (Plan de Management du projet ToIP), le Manager de Projet doit quotidiennement suivre et contrôler les points suivants : Le budget, les échéanciers et les milestones: on peut par exemple utiliser des checklists pour passer d’une étape à une autre comme suit : Questions sur le Réponse programme/projet Avez-vous abordé toutes les questions pendantes avant de clore cette phase ? L'analyse de pré-

investissement a-t-elle été réalisée et les résultats ont-ils été reportés ? Les archives relatives au projet ont-elles été créées et stockées selon les pré-requis relatifs à la gestion des archives du groupe? Questions relatives aux Réponse finances Les résultats financiers rapportés (réels dont produits à recevoir / charges à payer) au comité de restructuration (ou à l'organe directeur) correspondent-ils à ceux du grand livre ? La dernière estimation comptable (mise en vigueur graduellement) est-elle en

accord avec les résultats financiers réels et a-t-elle été incluse dans l'analyse mensuelle ? Questions sur la conception Réponse du processus opérationnel (incluant Sox) La personne responsable du management de la transition peut-elle garantir une prestation de services informatiques conforme aux exigences Sox ? Les sponsors clés et la direction comprennent-ils l'architecture du processus opérationnel visée ? Le processus a-t-il été bien défini et le modèle de propriété

des données a-t-il été réalisé ? L'identité du propriétaire des processus et données a-t-elle été formellement documentée et convenue ? Les processus opérationnels identifiés en tant que manuels ont-ils été documentés et convenus ? Questions sur le management de Réponse l'implémentation et du changement Les changements opérationnels visant à réaliser les valeurs et les bénéfices sont-ils réalisables ? Les bénéfices escomptés sont-ils réalisables ? Le projet incluait-il une évaluation de la capacité de

changement ? Les questions clés relatives au changement sont-elles connues et ont-elles été abordées ? Questions relatives à la gestion des données et des Réponse informations Les exigences pour la qualité des données ont-elles été convenues et documentées ? Questions relatives à l'élaboration des Réponse applications Les risques inhérents à l'élaboration des applications ont-ils été identifiés et les mesures d'atténuation appropriées / en vigueur ontelles été documentées dans le

registre des risques et les plans de gestion des risques ? Les systèmes actuels affectés par le projet ont-ils été identifiés ? Une évaluation de haut niveau des pré-requis du système a-telle été développée sur la base du plan du processus opérationnel de haut niveau ? Quel est le niveau de traçabilité des exigences de l'entreprise et des exigences non fonctionnelles inhérentes aux résultats attendus pour la spécification, la conception et le contrôle ? Comment les aspects liés aux

données inhérentes à la solution ont-ils été définis en matière d'intégration, d'interfaces, de modèle de données, de règles de validation, de données relatives à la migration et de pré-requis de conversion ? Quels sont les critères d'acceptation de la solution testée et ont-ils été approuvés par les parties intéressées ? Quelle est la structure du modèle de test global pour le projet, à savoir, sous forme de divers tests relatifs à l'intégration, l'aspect technique et la régression ? Dans quel ordre ces tests se déroulent-ils, quels sont les scénarios

couverts, de quelle manière les données sont-elles obtenues et quels outils seront utilisés ? Questions relatives à Réponse l'assistance (infrastructure, applications et services) Un/les gestionnaire(s) de la prestation de services a-t-il / ont-ils bien été engagé(s) et participe(nt)-t-il(s) activement au projet ? Un modèle d'appui a-t-il été ébauché et toutes les parties intéressées ayant un rapport avec l'assistance et l'organisation des opérations ont-elles été engagées ? Dans le budget du projet intermédiaire, un budget des dépenses a-t-il été prévu pour

la transition d'appui ? Une estimation des coûts a-telle été développée pour une exploitation et une gestion intégrale (licences, matériel, logiciels et ressources) ? Le mécanisme de recouvrement des coûts a-t-il été ébauché pour la facturation et le recueil de tarifs ? Les impératifs commerciaux relatifs à la solution IT ont-ils été établis avec les parties intéressées clés ?Les résultats escomptés pour une entente de niveau de service ont-ils été obtenus grâce à cela ? En se basant sur ces données, connaissez-vous le niveau du plan de reprise après sinistre

requis ? Êtes-vous en possession des informations nécessaires pour faire de bons choix en matière de conception de système et d'interface utilisateur, afin de satisfaire aux exigences de l'entreprise ? Questions relatives à Réponse l’approvisionnement (prestations externes) Si des tierces parties à facturer sont engagées durant cette étape projet, sont-elles sous contrat ? La stratégie de passer par une société de prestation externe at-elle été approuvée par le service des achats?

La stratégie a-t-elle été correctement exécutée (appel d'offres, etc.) ? Exemple 49: checklist pour passer d'une phase à une autre

Le fichier Log des Problèmes (Issues Log): tout Manager de Projet doit pouvoir rendre compte des problèmes survenus durant le projet dans un fichier qu’il met à jour au quotidien. Non seulement doivent y figurer les problèmes rencontrés, mais aussi les actions entreprises et qu’il convient d’entreprendre pour les résoudre, sans oublier d’affecter chaque action à une ressource, qui

doit à son tour monter un plan d’action pour les résoudre. Il convient également d’identifier la source des problèmes lorsqu'ils surviennent, car cela facilite la recherche de solutions. Selon Neal Whitten, dans son ouvrage Nononsense Advice for Successful Projects, tout Manager de Projet doit garder en tête les 3 premiers problèmes critiques qui affectent son projet et qui nécessitent une attention particulière. Cela ne veut pas dire que les autres problèmes sont de moindre importance, seulement qu’il ne faut jamais perdre de vue ces 3 premiers problèmes critiques, dont le

lourd impact sur l’issue du projet nécessite un management efficace.

Exemple 50 : Problèmes Log

“You will never find time for anything. If you want time, you must make it.”

Charles Buxton Le fichier Log des Risques (Risks Log) : tout Manager de Projet doit pouvoir non seulement identifier les

risques, ces événements susceptibles d’entraver la bonne réalisation du projet, mais aussi proposer un plan de contingence dans le cas où ces risques deviennent des problèmes avec impact néfaste sur le projet. Nous verrons, dans le paragraphe « outils et techniques », comment l’on identifie les risques et comment l’on évalue le facteur de risque sur le projet. Le management du projet revient à identifier régulièrement les risques et à mettre en place les plans d’action d’atténuation ou d’évitement de ces risques.

Exemple 51 : Risques Log

Le fichier Log des Demandes de changements (Change Request Log) : tout Manager de Projet doit contrôler et suivre toutes les demandes de changement survenues pendant le projet. Le Manager de

Projet doit saisir la nature du changement et les actions relatives au traitement de ce changement, ainsi que le résultat de la demande de changement et sa mise en place au cas où la demande a été acceptée. Le management de projet revient au processus de mise en œuvre du plan de management intégré des changements. Le rapport de performance : pour surveiller et contrôler proprement l’exécution du projet, il faut également mettre en place un rapport mensuel de performance afin d’évaluer si le projet peut toujours livrer les valeurs pour lesquelles il a

été lancé et faire du management en fonction. Le Manager de Projet et sa liste des actions

Chaque Manager de d’actions à réaliser, d Cette liste doit comp dans le Risks Log, le Log et celles déci nombreuses réunions le Manager de Projet liste et de même, à définir les actions pr 3 des problèmes renc La liste des actions explique les longues arrive même qu’on en

après ce travail. Il fau

Mettre en œuvre la maît changements de scope Toute demande de changement de scope souhaitée doit être soumise à un comité de changement de scope (Change Control Board ou CCB) via le formulaire de demande de changement (Exemple 52 : Formulaire de Demande de changement). Ce comité (CCB) passe en revue toutes les demandes de changement de scope, évalue

l’opportunité de les implémenter ou de les rejeter, et fait en sorte que les changements par lui approuvés soient incorporés dans les livrables, les coûts, les risques et le planning du projet. Cette activité est menée du début jusqu’à la fin du projet. Formulaire de Demande de changement Nom du Changement ID : changement : CRTOIP#1 Priorité : Niveau de Risque : 1 = Critique 2 = Majeure 1 = Haut 3 = Moyenne 2 = Moyen 4 = Mineure 3 = Bas 5 = Basse À réaliser par : Changement de

scope associé : Coût Délai d’implémentation d’implémentation : : Description du changement proposé, en incluant les bénéfices : Impact si le changement n’est pas effectué : Impact du pire scénario en implémentant le changement : Scénario de retour en arrière : Impact sur le service ou autre business en implémentant le changement : Comment ce changement peut-il modifier les paramètres du scope original :

Résolution : Approuvé Rejeté Date: Signature : Nom et Titre : (les membres du CCB ont la responsabilité de rejeter ou d’approuver les changements) Exemple 52 : Formulaire de Demande de changement

Clore le projet On a vu, dans la section 2 (référence), qu’un projet se termine quand il a atteint ses objectifs ou quand ses objectifs ne peuvent plus être atteints. Dans les deux cas, il faut toujours clore proprement le projet. Pour ce faire, le Manager de Projet doit préparer et mener soigneusement les actions suivantes : Vérifier que tous les objectifs du projet sont atteints ou bien documenter les raisons pour lesquelles le projet a été arrêté ; Rendre compte du résultat aux stakeholders, aux clients et à sa

direction ; Dans le cas où le projet est un succès, préparer le contrat pour le handover ou transfert du projet vers l’équipe qui s’occupera de la maintenance et du support du résultat du projet ; Dans le cas où le projet est un échec, faire une estimation du coût pour clore le projet et préparer le contrat pour mener les actions de clôture ; Dans les deux cas, documenter le retour d’expérience en prenant un recul sur le projet. Une organisation doit pouvoir continuellement tirer parti des leçons du passé, des

difficultés rencontrées, des échecs et des succès obtenus ; Terminer tous les contrats d’approvisionnement ; Archiver tous les documents du projet.

Management du scope du projet « Par le calcul, estimez si l'ennemi peut être attaqué, et c'est seulement après cela que la population doit être mobilisée et les troupes levées; apprenez à distribuer toujours à propos les munitions de guerre et de bouche, à ne jamais donner dans les excès du trop ou du trop peu.» Sun Tzu

Ce domaine de connaissance sur le management du scope du projet comprend les processus et les activités qui permettent de recueillir les besoins, de définir le scope requis pour le projet et de s’assurer qu’il est implémenté

durant le projet et que toute dérive de scope (scope creep) est contrôlée et maîtrisée.

Figure 30: Management du Scope du projet

(Source : PMBoK®) On ne le martèlera jamais assez, mais un Manager de Projet doit pouvoir manager

le scope, le scope et encore le scope et seulement le scope requis par le projet. On a vu que le scope est le total ou la somme des livrables à réaliser pour atteindre les objectifs du projet.

Recueillir les exigences On a vu qu’un projet est créé pour résoudre un problème et qu’il convient de bien s’accorder sur le problème dans son entièreté avant d’entamer sa résolution, afin d’en éradiquer non pas l’un des symptômes mais bien l’entièreté du problème. Ceci revient à recueillir les exigences du projet, étape où il faut clairement se poser la question des besoins réels du

client, du commanditaire et autres stakeholders du projet. Une mauvaise définition de ces besoins peut avoir un effet papillon sur le résultat du projet, à savoir qu’un changement mineur dans la définition du besoin est capable d’engendrer des conséquences considérables sur la solution à implémenter. Il est plus commode de développer un ensemble de besoins techniques et fonctionnels. Et pour ce faire, il faut aller recueillir ces besoins auprès des personnes pour qui le projet est créé, autrement dit, collecter la voix des stakeholders. On peut identifier trois sources pour collecter la voix des stakeholders: Information directe

Entretiens en face-à-face ou par téléphone ; En réalisant une étude par email, téléphone, ou des templates prédéfinis ; Réunion des commerciaux ; Feedback des employés. Observation En visitant le client ; En procédant à des tests de marketing ; Panel de clients ; Un salon ou forum. Recherche Analyse du marché ; Cahier de doléances, livre d’or, etc. ; Le registre des ventes ;

Publications ; Études commanditées. On peut identifier trois niveaux de besoins dans la voix des stakeholders : Les besoins de base, qui ne sont pas souvent exprimés tellement ils sont évidents. Par exemple, le client a besoin qu’on lui livre une voiture avec 5 portes et un porte-bagages sur le toit. Dans cet exemple, il va de soi que le client désire une voiture en parfait état de marche. Les besoins en termes de performance, qui sont souvent exprimés haut et fort par le client, mesurables directement et dont l’importance et la valeur ajoutée se

feront remarquer tout de suite s’ils font défaut dans la solution. Par exemple, le client veut une voiture qui peut parcourir une distance de 100 mètres en 4 secondes. Les besoins en termes d’excitation, qui ne sont pas connus voire pas espérés du tout par le client et dont l’importance et la valeur peuvent être spéculatives. On peut dire au client, par exemple, qu’on peut lui fournir une voiture qui non seulement peut faire du 100 mètres en 4 secondes mais qui peut aussi décoller et se transformer en avion. Toutefois, pour augmenter la chance de réussite d’un projet, il faut se

contenter de ne collecter que ce qu’il faut en termes de besoins, en se gardant d’en rajouter. Une fois que les besoins sont proprement collectés et bien définis, on peut alors passer à l’étape suivante pour déterminer le scope. Ce n’est que lorsqu’on dispose d’une idée claire et précise de nos besoins réels que l’on peut réussir. On ne le rappellera jamais assez mais un des facteurs d’échec d’un projet est la mauvaise définition des besoins.

Définir le scope Une fois les exigences recueillies, il faut passer à la définition

du scope. Il faut toujours garder en tête cette vision de la fin, du résultat, du produit tout au long du cycle de vie du projet et cette vision est offerte par le scope. L’énoncé du scope du projet comprend toujours une liste des livrables, les objectifs SMART du projet et une description des critères de succès du scope livré. Le livrable correspondant à ce processus est l’énoncé du scope (Exemple 53 : Énoncé du scope du projet ToIP). Impact d’une mauvaise définition du scope Si le scope n’est pas défini proprement, cela peut avoir un impact financier lourd sur le projet, car ceci revient à travailler et à retravailler le

livrable jusqu’à ce qu’on obtienne le résultat attendu. Cette attitude, ceci soit dit en passant, est une approche d’amateur sans méthodologie. Faire et refaire revient à dire que les exigences n’ont pas été recueillies proprement ou ne sont pas transcrites proprement dans la définition du scope. Une telle situation représente un coût et augmente le délai de livraison du projet. D’où l’importance de la vérification et du contrôle du scope. Un scope mal défini et non contrôlé entraîne une perte d’argent, de productivité et surtout de crédibilité du projet. C’est la route menant directement dans le mur de l’échec, où il ne reste plus qu’à nous lamenter. Plus la taille d’un projet est

grande, plus il est difficile de manager le scope d’où la nécessité d’une méthodologie et de bons processus pour contrôler le scope. Alors, minimiser le scope devient un moyen d’augmenter la chance de réussite d’un projet, de livrer dans les délais et budget impartis et, ce qui nous importe davantage, de livrer le projet à la grande satisfaction du client. Énoncé du scope du projet du ToIP

1. Objectif

L’objectif de ce projet est la téléphonie sur IP de plus compagnie multinationale. Il s’agit téléphonie existante, devenue obsolète nouvelle technologie IP. L’objectif du p pas être seulement d’équiper les emplo téléphones IP offrant plus de fo

également de réduire les dépens communications téléphoniques, ca communications de la ToIP (Téléph dérisoire en comparaison avec traditionnelles.

2. Scope

La solution choisie est une architecture PABX sera placé dans un datacenter en permettant la connexion de tous les site scope du projet sera donc le suivant :

1. Déploiement de la partie centr

centre de données (Datacenter) e 2. Déploiement du site en Afrique utilisateurs, que l’on rattache partie centrale (PC) ; 3. Déploiement du site en Asie utilisateurs que l’on rattache partie centrale (PC) ;

4. Déploiement d’un site en Eur

1000 utilisateurs que l’on rattach partie centrale (PC) ; 5. Déploiement d’un site en Am comprenant 1000 utilisateurs q par la suite à la partie centrale (P

3. Exclusion du scope

Le scope du projet ToIP ne compren place et en conformité du réseau cou LAN (câblage, QoS, alimentation sur partie WAN (débit, classes de service... pré-requis que chaque site doit mener budgets avant que tout déploiement ne

4. Frontières du projet ToIP 1. Dépendances : les déploieme

commencer que si les pré-requ qualité du réseau couvrant au

(câblage, QoS, alimentation su la partie WAN (débit, classes d bel et bien implémentés et respec 2. Hypothèses et Suppositions : équipements et la bascule des lig durant la nuit ou un week-end perturbations. Pour les sites co 500 utilisateurs, les bascules s tranche afin de minimiser les ris générale pendant la montée en façon, l'entreprise continue de d analogiques pendant que la progressivement. 3. Contraintes : il faut mettre multitude de compétence l'intervention d'experts en télép d'experts en réseaux IP, ainsi

irréprochable de projet méthodologie de management d

5. Critères de succès 1. La formation : il est indispensab

projet de fournir une formatio utilisateurs et aux administrateu Chaque formateur dispose du ch que les utilisateurs clés ou les qui agiront ensuite comme de leurs collègues. Outre la form mettre en place des petits gu manuels. 2. Management du changement : il irréprochable conduite du c d'éviter tout rejet de la nouv sous-estimation de l'impact solutions sur les habitudes des

être un facteur d’échec. Il fa d’accompagnement irréprochab avant, pendant et après la migra 3. Management du projet : le mana est l'un des aspects les plu déploiement de solution de ToIP 4. Collecte des données et des également impliquer très tôt les sont eux, au final, qui auro solution au quotidien. Les prin l'échec de projets de téléphonie pas dans d'improbables c technologie, c'est plutôt dans l'i requis, qu’il faut bien collecter.

6. Liste des livrables ID

Livrables non négociables

L1 L2 L3 L4 L5 L6 L7 L8 L9 L10

Spécification fonctionnelle et technique Rapport sur l’audit des sites Configuration Hardware du système Document d’architecture Plan de Management du Projet Rapport d’évaluation du réseau Rapport d’installation des sites Document de configuration Document de test de recette Document d’acceptation du site

Exemple 53 : Énoncé du scope du projet ToIP

Créer un WBS La WBS est le moteur qui fait tourner tout le projet. La WBS est un

outil pour organiser et définir le scope total du projet qui peut être critique pour donner une bonne estimation du projet. Les activités qui ne figurent pas dans la WBS ne font pas partie du scope.

WBS (Work Breakd hiérarchique, axée su projet doit exécuter p et produire les livra définit le contenu tota Définition 12: WBS

La WBS consiste à décomposer le projet (niveau 1) en différents sous-projets (niveau 2), lesquels se subdivisent encore en divers composants (niveau 3) et ainsi de suite en fonction du niveau de détail que l’on veut obtenir selon les informations que l’on dispose. Plus on

passe d’un niveau à un autre, plus détaillé en est le scope. La WBS ne montre pas la séquence selon laquelle les activités doivent être effectuées, cela représente juste un groupe d’activités pour réaliser les objectifs du projet. La WBS sera le cadre de toutes les estimations en délai et en coût. La WBS peut ne pas être symétrique, le niveau de détail peut être différent pour chaque groupe. Chaque tâche identifiée doit avoir un critère de finition et d’acceptation : on doit pouvoir déterminer si la tâche est achevée ou non et si elle est conforme à l’exigence du client.

Exemple 54: WBS du projet ToIP

En général, une WBS est accompagnée d’un dictionnaire de WBS (Exemple 55 : WBS Dictionnaire), dans lequel on trouve, comme dans tout dictionnaire, la

description, la définition de ce que comprend une tâche. ID 1.1

1.2

1.3

WBS Dictionnaire Définition Recueillir les exigences : faire l’inventaire de la situation actuelle des plans de numérotation, des lignes analogiques et numériques, de l’intégralité des liens télécoms, et collecter par la suite la cible que l'on souhaite atteindre. Concevoir la solution : définir une architecture conforme aux exigences ayant la capacité de s'intégrer à l'existant. Préparer l’intégration : réaliser une maquette afin de tester en conditions "réelles" les solutions

1.4

proposées et l’évaluer avec les utilisateurs clés. Migrer le site : commander et livrer les équipements, ensuite les installer, les configurer, les tester et, enfin, basculer les sites les uns après les autres durant les fins de semaine de préférence. Cette activité comprend la formation des utilisateurs. Exemple 55 : WBS Dictionnaire

Vérifier le scope Tout livrable à livrer au client est soumis à une vérification avec le même client afin de formaliser l’acceptation du livrable par le client. On est alors en phase « recette » du

livrable qui n’est autre que la vérification de la conformité de l'ouvrage à l’exigence formulée par le client. Ce dernier vérifie que le livrable respecte toutes les exigences le concernant, auquel cas le livrable est formellement accepté. Dans le cas contraire, il faut travailler de nouveau sur le livrable afin d’atteindre les exigences du client.

Exemple 56 : Vérification du scope

Dans le cas où le scope et notamment les critères d’acceptation sont mal définis, il arrive qu’on se renvoie la balle car le client n’accepte pas le livrable tel qu’il est alors qu’on a l’intime conviction qu’il est parfait. On se situe ici dans le cas où le client n’obtient aucune satisfaction et où il s’avère nécessaire de retravailler sur le livrable, ce qui coûte en temps et en argent. D’où l’importance de définir au préalable une bonne définition du scope et surtout des critères d’acceptation des livrables. La recette du dernier livrable marque la fin du projet, car si tous les livrables sont livrés, cela revient à dire que les objectifs du projet ont été livrés.

Contrôler le scope Tout au long du projet, le scope peut évoluer à travers les demandes de changement (Change Request) qui demeurent inévitables sur un projet. À travers ce processus, if faut une analyse de variance entre le scope défini et l’addition au scope, une évaluation des risques et des impacts sur le scope, le coût et le délai pour implémenter ce changement. Dans le formulaire de demande de changement (Exemple 52 : Formulaire de Demande de changement), il faut faire une recommandation au comité de changement de scope (CCB) sur les actions préventives ou correctives à mettre en place pour intégrer le changement et c’est au tour de

ce comité (CCB) d’approuver ou de rejeter la demande (voir processus – mise en œuvre de la maîtrise intégrée des changements de scope).

Management du Délai du projet « À la fin, ce ne sont pas les années écoulées de votre vie qui comptent, mais la vie qui a inondé ces années. » Abraham Lincoln

Un projet est limité dans le temps, il a un début et une fin déterminés. Le temps écoulé entre le début et la fin du projet représente la durée pour réaliser les objectifs du projet, et l’effort du management du projet consiste au management efficace de ce délai. Toutes les activités à réaliser pour atteindre les objectifs du

projet doivent être effectuées en respectant ce délai, qui est parfois imposé. Dans certains cas, tout retard de livraison du projet dans les délais impartis peut induire des pénalités proportionnelles au nombre de jours ou de mois de retard. Dans d’autres cas, cela peut tourner au scénario cauchemardesque quand on essaie de livrer un projet avec une contrainte de délai car le danger est de précipiter le projet avec le risque de réaliser les tâches à la hâte. C’était le cas du projet d’extension du stade de football de Furiani qui n’était pas prêt à temps avant le jour du match. Les organisateurs et les autorités compétentes laissèrent quand même le stade accueillir les spectateurs

dans les tribunes métalliques qui s’effondrèrent comme un château de cartes sous leur poids et précipitèrent 4.200 personnes dans le vide, plus de quinze mètres plus bas. Criant, le résultat de l’enquête laisse entrevoir les failles du management de ce projet : les gradins ont été construits sans plans préalables ni notes de calculs et qui plus est, ont été terminés à la hâte avec les moyens du bord, sans se soucier de la tragédie qui se tramait. Le management du délai est donc capital dans le management d’un projet. Il consiste à décider de la façon dont le temps sera utilisé pour réaliser le projet dans les délais impartis. L'objectif du management du temps court et du temps

long est d'identifier et d'adopter la manière la plus efficace de réaliser un projet. Le succès dans le management du temps lors d'un projet revient à l’application efficace du domaine de connaissances Management du Délai, qui n’est autre que l’application efficace des 5 processus qui lui sont associés.

Figure 31: Management du délai du projet (Source : PMBoK®)

Ce domaine de connaissances recouvre les processus nécessaires pour achever

le projet en temps voulu. Un management du délai efficace permet de s'assurer que le projet est réalisé dans les délais impartis. Il permet également d'empêcher le projet de dépasser le budget.

Définir les activités On a vu qu’un projet implique un groupe d’activités interdépendantes planifiées et exécutées afin de créer un produit unique ou un service dans un délai précis. Cet ensemble d’activités sera exécuté par les spécialistes de chaque discipline impliquée en faisant appel à des techniques (chemin critique, jugement d’experts, Precedence Diagramming Method, Schedule Value,

etc.) et en utilisant les outils appropriés (Figure 32 : Un projet implique un groupe d’activités interreliées). Le processus « Définir les activités » revient, à partir de l’énoncé du scope et du WBS, à faire une liste exhaustive des activités nécessaires à entreprendre pour réaliser les objectifs du projet. Ces activités peuvent être constituées de plusieurs tâches (Exemple 58 : Liste des activités du projet ToIP).

Figure 32 : Un projet implique un groupe d’activités interreliées

Définir les activités revient également à dresser une liste des milestones ou jalons, qui sont les points ou événements significatifs du projet (Exemple 57 : Liste des Milestones).

M1 M2 M3 M4 M5 M6 M7

Milestones Fin de collectes de données Architecture finalisée Audit du réseau (WAN, LAN) effectué Équipements reçus sur sites Site central déployé Site Afrique déployé Site Asie déployé

D Ju Ju A

A S O N

M8 M9 M10

Site Europe déployé Recette de tous les sites Transfert de tous les sites aux équipes de Support et Maintenance

D Ja

Ja

Exemple 57 : Liste des Milestones

Activités du projet ToIP 0. Phase 0 : kick-off 1. Phase 1 : Recueillir les ex a) Recueillir les spécifications fo utilisateurs ; b) Recueillir les spécifications tec c) Faire l’inventaire de la numérotation, lignes analogiques liens télécoms ; d) Réfléchir à la cible que l'on so e) Valider les performances du une charge supplémentaire et à su

f) Faire le bilan des équi documenter les besoins supplém ToIP. 2. Phase 2 : Concevoir la solution - d a) Analyser la faisabilité et vér peut répondre aux exigences du des équipements à intégrer à l'exis b) Faire l'inventaire fonctionnel voir s'il correspond au cahier des c c) Analyser les performances LAN) en prenant en compte d'interopérabilité ; d) Écrire le document d’architect 3. Phase 3 : Préparer l’intégration a) Réaliser une maquette afin d les solutions proposées et vérifier aux spécifications fonctionnelles, m critères de disponibilité et de toléra configuration multi-site) ; b) Développer les interfaces ave

système d'information tels que métiers (CRM, gestion de conta données...) ; c) Évaluer la solution avec les uti 4. Phase 4 : Déployer la solution a) Déployer la solution au datace i) Commander et livrer les éq ii) Installer et configurer le PA iii) Faire les tests d’acceptation b) Déployer les sites Afrique ; i) Commander et expédier les ii) Installer et configurer les éq iii) Faire les tests d’acceptation iv) Basculer les sites les uns ap v) Former les utilisateurs sur c c) Déployer les sites Asie ; d) Déployer les sites Europe ; e) Déployer les sites Amérique. 5. Phase 5 : Clôturer le projet ToIP a) Mener une session avec l’éq

pour récolter les retours d’ex documentant les difficultés renco l’on a raté ou moins bien réalisé, réussi et plutôt bien réalisé sur le p b) archiver tous les livrables et base de données des historiques d c) relâcher l’équipe du projet l’organisation ; d) terminer les relations contr prestations ; e) archiver tous les documents co f) Célébrer la fin du projet. Exemple 58 : Liste des activités du projet ToIP

Organiser les activités en séquence Les groupes d’activités du projet sont interreliés et doivent être

planifiés et exécutés selon une certaine séquence. Ainsi, une fois que la liste des activités est définie, il faut déterminer l’ordre le plus approprié dans lequel on veut que les tâches soient exécutées. Il ne faut pas avoir peur d’utiliser des post-it surtout quand on détermine l’ordre avec son équipe ou avec un groupe de personnes. C’est un exercice assez ludique où l’on mélange le fun et le travail. À chaque post-it, on attribue une activité ; ensuite, on place les activités les unes derrière les autres ou en parallèle avec les autres : cela aboutit à une représentation schématique des liens logiques entre les activités du projet dans l’ordre chronologique. On se réfère, dans ce cas, à la technique des

PDM (Precedence Diagramming Method) ou encore méthode des antécédents dans laquelle les activités du planning sont représentées par des rectangles (nœuds).

Exemple 59 : Organiser les activités en séquence : Diagramme de Réseau

On verra en profondeur cette technique ainsi que les contraintes que peuvent

rencontrer chacune des activités ou des tâches dans la section sur les « outils et techniques ». En effet, il existe 4 types de contraintes ou de liens d’interdépendances entre les tâches : 1. Début à Début (DD) : une tâche ne peut démarrer que si la tâche avec laquelle elle est en relation DD commence. Par exemple, la tâche « configuration Asie » ne peut commencer que si la tâche « configuration Afrique » a démarré. 2. Fin à Début (FD) : le travail de la tâche successeur peut commencer quand le travail de la tâche prédécesseur est terminé. Par

exemple, l’activité « concevoir la solution » ne peut commencer que quand l’activité « recueillir les exigences » est terminée. 3. Fin à Fin (FF) : une tâche ne peut se terminer que si la tâche avec laquelle elle est en relation FF est terminée. Par exemple, la tâche « Test&Recette Europe » ne peut se terminer que si la tâche « Test&Recette Amérique » est terminée. 4. Début à Fin (DF) : dans les planifications juste à temps (Justin-Time), la tâche prédécesseur qui doit être planifiée juste à temps et

sa tâche successeur correspondante ont une relation DF. Mais, dans la réalité, ce type de relation se produit moins souvent que les autres. Oui, vous pouvez faire l’impasse sur ce type de contrainte. Quand on organise les activités d’un projet en séquence, il est également important de connaître les notions suivantes : Lead ou Avance (Modification d’un lien logique permettant d’accélérer l’activité successeur) : quand on veut superposer 2 tâches en faisant commencer la tâche successeur bien avant que la tâche prédécesseur ne soit terminée. Dans

l’exemple ci-dessous, la tâche « Test & Recette Afrique » peut démarrer 2 jours avant la fin de la tâche « Test & Recette Datacenter ».

Exemple 60 : Lead ou Avance

Lag ou Retard (Modification d’un lien logique permettant un retard de l’activité successeur) :

quand on veut créer un temps de latence avant que la tâche successeur ne commence quand la tâche prédécesseur est terminée. Dans l’exemple ci-dessous, la tâche successeur ne peut commencer que 15 jours après la fin de la tâche prédécesseur, du fait du délai d’expédition des équipements.

Exemple 61 : Lag ou Retard

Lorsque les tâches ne sont soumises à aucune contrainte et n’ont aucune

relation d’interdépendance avec les autres, elles sont dites indépendantes et peuvent s’effectuer à tout moment durant la réalisation du projet. Certains managers de projet ne prennent pas le temps de préparer le diagramme de réseau, qui offre une vue d’ensemble des liens logiques entre les activités, et organisent directement les séquences des activités dans les outils tels que MS Project, Primavera ou autre. Certes, cela peut marcher car cela fait gagner du temps mais c’est moins pratique, le drag and drop est moins facile avec ces outils. En ne listant que les activités,

sans établir de durée, mais en tenant en compte des relations d’interdépendance entre ces activités, ils arrivent tout de suite au résultat ci-dessous. Cette approche a l’avantage de mettre en évidence les milestones du projet.

Exemple 62 : Organiser les activités en séquences sur MS Project

Estimer les ressources nécessaires aux activités Ce processus consiste à identifier les ressources nécessaires pour le projet dans son intégralité. Cette activité se fait en relation avec le processus d’estimation des coûts du domaine de connaissance du management des coûts car chaque ressource représente un coût. Il est important de garder à l'esprit que les ressources comprennent les personnes, ainsi que l'équipement et le matériel. Toutefois, plusieurs types de ressources sont à distinguer : Ressource renouvelable:

ressource qui, après avoir été allouée à une ou plusieurs tâches, est à nouveau disponible en même quantité. L’architecte qui a travaillé sur le premier site peut être rappelé sur le deuxième site si les deux sites ne se font pas en parallèle. Les équipements utilisés pour l’évaluation du réseau (WAN, LAN, etc.) du premier site peuvent être réutilisés pour le deuxième site si les deux sites ne se font pas en parallèle. Les coûts, dans ce cas, sont souvent prélevés parmi les budgets OPEX. Ressource consommable : quand une ressource n’est pas

renouvelable, elle est consommable. Son utilisation est instantanée et limitée dans le temps. L’argent n’est utilisé qu’une fois sur une activité. Le PABX, une fois installé, n’est plus utilisé. Pour estimer les ressources nécessaires aux activités d’un projet, on peut faire appel à une méthode heuristique au moyen de règles empiriques, en fouillant dans la base de données historiques de projet de l’organisation. Un autre moyen est de s’entretenir avec les experts de chaque activité. Dans les deux cas, il faut aboutir à un résultat comportant une liste exhaustive des ressources nécessaires au moyen d’un RBS (Resources Breakdown Structure) ou

d’un autre format.

Estimer la durée des activités Le processus « estimer la durée des activités » consiste à estimer le temps nécessaire pour réaliser les activités individuellement, mais aussi le projet dans son intégralité. Chaque tâche faisant partie d’une activité est une entité élémentaire localisée dans le temps par une date de début et/ou de fin, dont la réalisation nécessite une durée qu’il faut estimer à l’avance. Il y a plusieurs façons d’estimer la durée de chaque activité, comme en faisant appel à un

jugement d’experts, par exemple, ou en se basant sur sa propre expérience. Il suffit simplement d’estimer le nombre de jours nécessaires pour réaliser chaque activité et d’en déduire le nombre de jours total pour réaliser le projet dans son intégralité. Dans l’exemple cidessous, il faut 98 jours pour réaliser le projet dans son intégralité. Cette durée est donnée par le chemin critique.

Exemple 63 : Estimation des durées des activités d'un projet

La séquence d'activités la plus longue est appelée chemin critique. Tout retard accusé dans une des activités constituant le chemin critique a une incidence sur l'intégralité du projet.

Élaborer l’échéancier du projet « No battle plan survives contact with the enemy.» Helmuth von Moltke Le processus « Élaborer l’échéancier du projet » est plus connu en France comme le planning. Il s’agit, dans cette partie, de combiner les résultats des 4 autres processus précédemment vus : Définir les activités ; Organiser la séquence des activités ; Estimer les ressources nécessaires aux activités ;

Estimer la durée des activités. L'élaboration de l’échéancier nécessite l'allocation de temps pour chacune des activités en fonction de la disponibilité des ressources et des limites budgétaires. Par exemple, si la durée d’une activité doit être d’une semaine et qu’une ressource n’est disponible que 35h dans une semaine, il faut alors prévoir une deuxième ressource pour réaliser le travail dans le délai défini. Donc, un problème que peut rencontrer le Manager de Projet est d’organiser dans le temps la réalisation de tâches, compte tenu de contraintes temporelles (délais, contraintes d’enchaînement) et de contraintes portant sur la disponibilité des ressources requises. Il

est de coutume de mettre les meilleures ressources sur les activités du chemin critique, car un retard sur ce dernier cause un retard sur l’intégralité du projet. Le challenge est donc, pour le Manager de Projet, de combiner le calendrier de disponibilité des ressources avec la durée des activités et les deadlines forcés ou autres types de contraintes pour effectuer chacune des activités du projet dans les délais impartis. L’échéancier développé est très souvent représenté par un diagramme de Gantt (Figure 71: Planification et suivi des activités (Diagramme de Gantt). Il ne faut jamais s’engager sur un planning détaillé pour un projet de

longue durée. Il faut aller dans les détails sur le temps court et rester « high level » sur le temps long. En effet, il peut se passer plusieurs choses entretemps. Pour ce faire, il faut utiliser la technique de l’élaboration progressive.

Élaboration Progre continu d’un plan au détaillées et des estim durant le déroulemen et fiabilité du process à ces itérations succe Définition 13: Élaboration Progressive

L’échéancier qui vient d’être développé doit être considéré comme le planning de référence (baseline) sur base duquel on mesurera tout avancement et la

performance sur le projet.

Maîtriser l’échéancier “The Plan is the first casualty of War” Attribué à Napoléon Aucun planning ne peut garantir qu'un projet se déroulera comme prévu du début à la fin, d’où l’importance de le contrôler et de maîtriser l’échéancier à tout moment du projet. Le contrôle de l’échéancier permet d'envisager les facteurs pouvant avoir une incidence sur le planning d'origine et de les manager en conséquence. Avant toute exécution d’un projet, le Manager de Projet doit disposer d’un planning de référence

(schedule baseline) sur base duquel il peut évaluer l’avancement et le progrès du projet. Nous verrons, dans le paragraphe sur les « outils et techniques », les techniques (Earned Value, Schedule Value, Fast tracking, Crashing, EVM, etc.) pour suivre la performance du projet en terme de planning mais, en général, il faut comparer l’état actuel au moment du contrôle par rapport à l’état de référence (baseline). Dans l’exemple ci-dessous (Exemple 64 : Contrôle et suivi des échéanciers (planning)), la tâche ID#1 (Phase 0 : Kick-off) a été effectuée à 100% dans les délais impartis ; en revanche, la tâche ID#2 (Phase 1 :

collecte des exigences) n’est effectuée qu’à 32% et son délai de livraison accuse un retard de 4 jours : en effet, elle devait prendre 10 jours mais on constate qu’elle ne peut aboutir que 4 jours plus tard. Le Manager de Projet doit donc faire du management en analysant la cause du retard et son impact sur le reste du planning. En fonction du résultat, il doit prendre des mesures correctives pour remédier à ce retard et des mesures préventives sur les autres actions qui dépendent de cette tâche ID#2 ; ensuite, il doit intégrer, dans son nouveau planning, l’implémentation de ces mesures.

Exemple 64 : Contrôle et suivi des échéanciers (planning)

Le contrôle du planning d'un projet et le respect de ses délais peuvent être facilités par le calcul de l'écart de délai

(Schedule Variance - SV). Pour le calcul, il faut considérer les suivantes : Earned Value (EV): c’est la valeur acquise ou encore le coût budgété pour le travail effectué jusqu’au moment où l’on fait le calcul. Planned Value (PV): c’est la valeur planifiée ou encore le coût budgété du travail prévu. C’est le coût prévu dans le budget pour les activités planifiées jusqu’au moment où l’on fait le calcul. Ce calcul consiste à évaluer le coût

budgété du travail effectué (EV) par rapport au coût budgété du travail prévu (PV) et l’écart de délai ou de prévision s’effectue comme suit : Schedule Variance (SV) [SV=EV-PV] Le SV s’interprète comme suit : SV <0 : le projet est en retard par rapport au planning car un volume de travail inférieur au volume prévu a été accompli à ce stade. SV>0 : le projet est en avance par rapport au planning car un volume de travail supérieur au volume prévu a été accompli à ce

stade En fonction de cette information, le Manager de Projet fait du management en effectuant les ajustements nécessaires en implémentant des mesures préventives pour conserver l’avance ou, au contraire, en implémentant des mesures correctives pour rattraper le retard.

Management du coût du projet « Car l’amour de l’argent est la racine de tous les maux. » Timothée, VI, 10, Bible

On dit que l’argent est l’un des puissants leviers du pouvoir dans le couple et que c’est aussi une des principales sources de conflits, surtout quand il n’y en a pas ou pas assez. C’est aussi le cas sur un projet. Il n’y a pas de projet si l’on ne trouve pas de sponsor pour le financer. En effet, chaque activité sur le projet a un coût. Encore faut-il savoir estimer le montant nécessaire pour réaliser ce projet. Une fois le montant obtenu, il faut encore pouvoir le dépenser proprement sans le gaspiller et sans sortir des objectifs du projet. Pour ce faire, il faut maîtriser ce montant tout au long du projet. Ce domaine de connaissance comprend les activités qui permettent

aussi bien d’estimer les coûts et d’établir le budget d’un projet, que de maîtriser les coûts de façon à ce que le projet soit achevé dans le budget approuvé, en livrant les objectifs pour lesquels il a été démarré et financé.

Figure 33: Management du coût du projet (Source : PMBoK®)

Le plan de Management du projet, notamment le plan de Management des Coûts, devrait comprendre les recommandations à suivre pour manager les écarts des coûts.

Plan de Management des coûts du Introduction

L’objectif de ce document à mener durant le projet en

Mise en place du management des

Une commande SAP est créée pour r effectuée au cours du projet doit être im Le budget enregistré sur ce numéro de suivants : 1. Un budget CAPEX: couvre les (prestation de service par une soc matériels divers. 2. Un budget OPEX : couvre le

œuvrant sur le projet.

Le budget du projet a été estimé avec +/-10% en utilisant une méthode param ont été estimés en jour-personne, et l’unité. L’estimation et les rapports mensuels su EURO (€).

Outils

Un fichier Excel est mis en place pour l

Financement du projet

Le projet sera financé comme suit : 1. 100% du budget CAPEX par le c 2. 70% du budget OPEX par le clien 3. 30% du budget OPEX par le Bus le contrat)

Le propriétaire du budget (Budget Own

Le budget est disponible à 100% au déb Toute demande d’extension du budget s Moins de 15% du budget tota une demande auprès du budge d’exception justifiant sa demande Au-delà de 15% : le Manage committee en appuyant sa deman

Les raisons d’une extension du budget p Le Comité du Contrôle de Cha de modification, ce qui nécessite Risques inconnus non capturés Tout litige avec le client sera managé co

Estimation des coûts

La première estimation des coûts a été évaluation devra être révisée à la fin de aura défini toutes les activités utiles à la

Les provisions pour les risques ont ég l’estimation.

Budget

Le budget couvre tout ce qui a été comprend pas les coûts des ressources à travailler sur le budget. Les réserves sur le budget peuvent être committee. La référence des coûts (cost baseline) design. Tout suivi de coût se fondera su

Contrôle des coûts

L’équipe projet fournira un timesheet imputant son temps passé sur le proje pour le projet. Toute commande d’équipement et de m coût du projet. L’équipe financière enverra au M hebdomadaire reprenant les achats pa

attribué au projet. Le Manager de Projet utilisera la techn analyser la performance et les prévision Le Manager de Projet rédigera un rappo Mensuellement au steering com Prévisions des coûts Les coûts réels engagés (O Le budget CAPEX: Vale Acquise Le budget OPEX : Vale Acquise

Hebdomadairement, dans son t Les coûts réels engagés (O Valeur Planifiée vs Coû CAPEX) Les déviations des coûts par rapport traitées comme suit :

Projet représentant un surcoû un surcoût par rapport à la référe mais si, toutefois, il est récup contentera d’écrire un rapport d légère dérive du coût. Projet représentant une dé surcoût n’est plus récupérable refinancement du projet auprès d est inférieur à 15%, et auprès d contraire. Exemple 65: Plan de Management des coûts du projet ToIP

Estimer les coûts ROM (Rough Order of Magnitude) Estimer des coûts fait partie du

quotidien du Manager de Projet tout au long du cycle de vie du projet. C’est une partie déterminante dans le management de projet parce que l’issue du projet en dépend. Si l'estimation des coûts totaux pour réaliser le projet est trop basse, le risque est très grand de mettre en danger la réalisation du projet à moins que le sponsor n’accorde une rallonge aux coûts estimés en cours de projet ou qu’un autre sponsor vienne secourir le financement du projet. Si, au contraire, l'estimation des coûts totaux pour réaliser le projet est trop élevée, il y a le risque de ne pas trouver de sponsor pour financer le projet. La technique d’estimation est une science que le Manager de Projet devrait maîtriser tout

au long de son parcours professionnel en management de projet. Nous verrons, dans la section « Outils et techniques », les différentes méthodes et techniques pour estimer les coûts du projet. Cette estimation des coûts totaux pour réaliser le projet doit toujours comporter une indication de précision d’ordre de grandeur ou ROM (Rough Order of Magnitude) (+/- x%) : Estimation avec un ordre de grandeur (ROM) de ± 50%: cette estimation se fait à un stade où l’on a très peu d’informations sur le projet, où l’on ne connaît que les grandes lignes. On retrouve souvent ce genre d’estimation dans les livrables comme un Business Case

ou un Project Charter. L’estimation à ce moment du projet est souvent moins précise car elle comporte une précision d’ordre de grandeur (ROM) de ± 50%, à savoir qu’il y a 50% de probabilité que le coût total pour réaliser le projet soit en deçà ou au-delà des coûts estimés. Les estimations faites à ce stade sont en général stratégiques car le but final est d’avoir une idée du coût total nécessaire pour réaliser le projet. Ce coût estimé peut alors servir à déterminer les besoins de trésorerie, à prendre les décisions appropriées - comme déterminer si le projet vaut la peine d’être entrepris ou convaincre les

sponsors de financer le projet - ou encore peut influencer la négociation commerciale en cours pour vendre le projet. En tout cas, ce coût estimé à ce stade propose des choix sur ce qu’il est possible de faire sur le projet, qui peuvent lever des incertitudes majeures liées à ce même projet. Ces incertitudes peuvent concerner les coûts de la partie technique, légale, sociale, etc. L’estimation peut donc crédibiliser le projet auprès des décideurs ou acheteurs potentiels du projet. En gros, à ce stade, le calcul prévisionnel des coûts doit répondre à la question de ce qu’il est raisonnablement possible de

supposer que le projet coûtera. Estimation avec un ordre de grandeur (ROM) de ± 10%: cette estimation est plus précise et elle se fait à un moment où le projet est déjà initialisé et où des informations plus détaillées (WBS) sont disponibles. On peut ainsi affiner la première estimation avec un ordre de grandeur de ± 10%, à savoir qu’il y a seulement 10% de probabilité que le projet ne se termine pas dans le budget estimé. Cette estimation n’est possible que quand on a déjà estimé la durée des activités et défini les types et quantités de ressources nécessaires

pour chacune des activités. On se repose sur les WBS et ses règles de 100% pour réaliser ce type d’estimation.

Exemple 66: Estimation de coût à partir du WBS avec Compte de Contrôle

Facteurs à prendre en compte dans l’estimation des coûts Pour réaliser le projet, il faut estimer tous les coûts directs et indirects imputés au projet. En général, il faut tenir compte au minimum des facteurs suivants : Les ressources humaines: les ressources internes et externes qui ont des activités sur le projet. Coûts des équipements et matériels: surtout les acquisitions d’équipements ou de logiciels et autres périphériques, les outils

d’installations, peinture, etc. Les infrastructures : coût de location ou d’achat. Le contrat d’approvisionnement: dans le cas où l’on fait un achat ou l’acquisition d’une solution, d’un produit, d’un service externe. Les frais généraux: les coûts impliqués dans la maintenance de l’environnement du projet, les fournitures, les impressions d’affiches ou de posters, téléphone, etc. Support des différents services :

certains services tels que l’obtention d’un support peuvent être payants. Formation : certaines ressources nécessitent une formation avant d’entamer un projet, d’où l’empressement des entreprises à embaucher des consultants externes qui n’ont pas besoin d’être formés pour le temps du projet. Frais de mission (billets, repas, taxi, etc.) : les déplacements dans le cadre du projet sont imputés sur les coûts du projet. Coûts des salles de réunions (salles, téléphones, etc.) : il arrive,

quand l’équipe n’est pas locale, que les réunions se passent dans des hôtels, des aéroports ou d’autres lieux offrant cette possibilité. Il faut savoir que pour certains projets, même si l’équipe est locale, pour des raisons de confidentialité ou tout simplement dans le cadre d’un teambuilding, les réunions se passent en dehors des locaux de l’entreprise. Les provisions pour les risques : L’estimation est faite dans les conditions normales, où tout se déroule comme prévu. Mais dans un projet, tout ne se déroule jamais comme prévu et les choses peuvent aller mal. Il faut identifier les risques

sur un projet, qui sont des problèmes potentiels susceptibles de mettre en danger la réussite du projet. Transférer, éviter ou atténuer ces risques s’ils se transforment en problèmes génère des coûts qu’il faut prévoir dans la réserve. Ces facteurs à prendre en compte varient d’un endroit à l’autre, alors si le projet est international, il faut tenir compte de la réalité du pays. Dans l’exemple cidessus, vous pouvez constater que si les efforts sont les mêmes pour effectuer une activité, les coûts restent différents car le coût de la main-d’œuvre change en fonction du pays.

Déterminer le budget

Ce processus revient à additionner tous les coûts estimés pour obtenir les coûts totaux pour réaliser le projet, ce qui n’est autre que le budget initial du projet que le Manager de Projet est autorisé à dépenser sur le projet. Ce budget échelonné en fonction du planning sert de référence de base (cost baseline) pour mesurer la performance du projet.

Exemple 67: Budget du projet ToIP

Maîtriser les coûts

Il ne faut jamais perdre de vue qu’il faut livrer le projet dans le budget défini et approuvé. Le Manager de Projet n’est pas autorisé à dépenser 1€ de plus sauf stipulé autrement dans le Plan de Management des Coûts. Ainsi, il est crucial de connaître à tout moment l’état des dépenses déjà engagées et celles qui restent à engager pour réaliser les objectifs du projet. Le vrai management de projet s’effectue lorsqu’on joue avec les mesures correctives ou préventives afin de permettre l’achèvement du projet dans les délais et budgets prévus. Comme pour le planning, avant toute

exécution d’un projet, le Manager de Projet doit disposer préalablement d’un budget de référence (cost baseline) sur base duquel il peut comparer l’état financier du projet tout au long de son déroulement. Nous verrons, dans le paragraphe sur les « Outils et techniques », les techniques (Earned Value, Schedule Value, EVM, etc.) pour suivre la performance du projet en terme de coûts. Contrôle des coûts Le contrôle des coûts d'un projet peut être facilité par le calcul de l'écart de coût ou Cost Variance (CV). Pour le calcul, il faut considérer les suivants : Earned Value (EV) ou Valeur

Acquise : c’est la valeur acquise ou encore le coût budgété pour le travail effectué jusqu’au moment où l’on fait le calcul. Actual Cost (AC) ou Coût Réel : cette valeur correspond au coût réel du travail effectué. On fait ici l’addition de tous les coûts imputables au projet pour réaliser le travail effectué. Cela comprend les coûts directs ainsi que les coûts indirects. Ce calcul consiste à évaluer la différence entre le coût budgété du travail effectué (EV) et le coût réel (AC). L’écart de coût s’effectue comme

suit : Cost Variance (CV) [CV=EV-AC] Le résultat du CV s’interprète comme suit : CV <0 : le projet dépense plus que prévu, on perd de l’argent, il faut comprendre pourquoi le projet dépense plus qu’il ne le faut et apporter des mesures correctives afin d’y remédier. CV>0 : le projet dépense moins que prévu, le Manager de Projet est un économe et maîtrise les coûts dépensés sur le projet. En fonction de cette information, le

Manager de Projet fait du management en effectuant les ajustements nécessaires. Performance du projet en termes de coûts Il est aussi important de connaître à tout moment la performance du projet en termes de coûts, ce qui peut être facilité par le calcul de l’Indice de Performance des Coûts (CPI : Cost Performance Index). Le CPI est le rapport entre le coût budgété du travail effectué (EV) et le coût réel (AC). Cost Performance Index (CPI) [CPI

=

]

Le résultat du CPI s’interprète comme suit : CPI < 1 : le rendement du projet en termes de coût est faible. Si le CPI vaut 0,67 au bout de 3 mois sur le projet, cela veut dire que pour 1€ investi sur le projet, on en récupère 67 centimes d’euro en valeur de travail effectué au bout de 3 mois. CPI > 1 : le projet a un bon rendement en termes de coût. Si le CPI est à 1,30 au bout de 3 mois, cela veut dire que pour 1€ investi sur le projet, on en récupère 1,30€ en

valeur de travail effectué. Le Manager de Projet peut se féliciter ici. Mais cela arrive rarement sur un projet. Mesures de Prévision en termes de budget En effet, le Manager de Projet doit, au moment de son rapport, avec les informations à sa connaissance, évaluer l’impact de l’état financier actuel du projet sur le budget total défini pour sa livraison. À cette fin, le Manager de Projet doit se demander si, selon l’état financier actuel, il peut toujours livrer le projet dans le budget imparti ou s’il faut faire une demande de budget supplémentaire auprès du sponsor. Pour ce faire, à partir de l’état actuel

financier, le Manager de Projet doit faire une estimation du montant nécessaire pour réaliser le projet, et faire du management de projet en conséquence, ce qui revient à estimer le montant des mesures correctives et préventives à prendre pour livrer les objectifs du projet. Avec la méthode des Earned Values (EV) ou Valeurs Acquises (VA), on peut également mesurer les prévisions en termes de budget à partir d’informations et de connaissances disponibles au moment où ces prévisions sont effectuées. Pour ce faire, on peut faire appel aux suivants : Coût Final Estimé ou Estimate at Completion (EAC) : on fait une

estimation des prévisions sur le coût total à la fin du projet à partir du Budget en fin de parcours ou Budget at Completion (BAC), qui n’est autre que le budget initialement planifié pour faire le projet. Elle se calcule comme suit : [EAC=BAC/CPI] Il se peut que, le budget total initialement prévu ne soit plus viable, ainsi, le Manager de Projet doit vraiment chercher d’autres fonds auprès du sponsor sinon le projet se trouverait en danger. Le BAC correspond à 1,23M€ dans notre exemple, (Exemple 67: Budget du projet ToIP) ou le budget Total

CAPEX vaut 975k€ et le budget Total OPEX vaut 348k€. Coût Estimé pour achèvement ou Estimate to Complete (ETC) : on peut estimer le coût nécessaire pour achever le travail qui reste à faire pour terminer le projet. En d’autres termes, cela répond à la question du coût restant nécessité pour finir le projet. Il se calcule comme suit : [ETC=EAC-AC] La comparaison du coût que l’on vient d’estimer pour mener le projet à son terme avec le budget restant nous indique si le budget a besoin de rallonge ou pas. Le management du

projet se fait en conséquence suivant ce qui est défini dans le plan de management de coûts (Exemple 65: Plan de Management des coûts du projet ToIP). En résumé, ce processus permet d’avoir une représentation de l’état de dépenses du projet à un instant donné et il permet également d’estimer les prévisions pour terminer le projet.

Management de la qualité du projet « La qualité de la vie d'une personne est en rapport direct avec sa volonté d'exceller, quel que soit le domaine où elle s'exerce. » Vince Lombardi

La satisfaction d’un client est directement liée à la qualité du résultat, du produit ou du service final livré par le projet. Il va donc sans dire que le management de la qualité sur un projet revêt une importance capitale. Six Sigma est une méthodologie réputée pour sa méthode structurée de management,

visant à une amélioration de la qualité et de l'efficacité des processus. Le management de la qualité est un domaine de connaissance qui comprend les activités de planification et de mise en œuvre de l’assurance et du contrôle de la qualité du projet. Les processus lui correspondant doivent faire partie des activités de routine du Manager de Projet. Livrer un projet de qualité ne doit pas être qu’un acte. Cela doit également devenir un automatisme pour le Manager de Projet. L'habitude est le grand guide de la vie. Selon David Hume dans A Treatise of Human Nature, c’est ce principe seul qui rend l’expérience profitable et qui

permet d’anticiper à l’avenir une suite d’événements semblables à ceux constatés dans le passé. Sans l’influence de l’habitude, nous ne connaîtrions de faits que ceux immédiatement présents aux sens et à la mémoire et nous ne saurions ajuster les moyens aux fins ou employer nos pouvoirs naturels à la production d’un effet voulu. Le domaine de connaissance du management de la qualité du projet recouvre les processus nécessaires (voir figure ci-dessous) à la vérification du fait que les résultats satisferont les besoins qui ont menés à l’entreprise du projet.

Figure 34: Management de la qualité (Source : PMBoK®)

L'assurance qualité (dans le processus « mettre en œuvre l’assurance qualité ») fait référence aux activités de projet planifiées et exécutées pour garantir la qualité et la conformité aux normes en vigueur du résultat, du produit ou du service livré par le projet. Les activités de l’assurance qualité

peuvent s’organiser comme suit: Les activités qui s’assurent que le projet est bien défini, qu’il dispose des ressources nécessaires et qu’il est bien piloté pour réaliser les objectifs du Business. Les activités qui s’assurent de la conformité et de la qualité de la solution à livrer en rapport avec les besoins des stakeholders, et les objectifs du projet. La mise en place d’un mécanisme de porte d’étape, souvent caractérisé par des checklists à chaque fin d’étape, qui assure un contrôle progressif des livrables tout au long des phases et différentes étapes du

projet. Les coûts de la qualité (Cost of Quality – COQ) Vous avez peut être lu l’excellent ouvrage de Philip B. Crosby traitant de l’art et la manière d’obtenir la qualité, « La qualité, c’est gratuit ». Mais sur un projet, je peux vous assurer que la qualité n’est jamais gratuite, même si bien souvent, hélas, les activités relatives à l’assurance qualité sont comprises dans les overhead ou frais généraux du budget du projet. En effet, les managers de projet estiment rarement les coûts associés à la qualité dans le budget du projet. Pourtant, c’est l’une des activités les plus importantes, non

seulement parce qu'elle conduit à la correction des problèmes, mais aussi parce qu'elle donne confiance aux intervenants et aux clients en un produit fini exempt de défauts. Le coût pour retravailler sur le résultat, le produit ou le service livré par le projet est souvent plus élevé que le coût de la qualité luimême. (Cost of Quality – COQ): ce terme désigne les coûts induits tout au long de la vie du produit en investissant sur les actions de prévention de nonconformité aux exigences. Il existe également des coûts de l’échec (Failure cost), ou encore coûts de la mauvaise qualité, aussi bien trouvés

en interne durant l’exécution du projet qu’en externe, alors découverts par le client. La méthode statistique Design of Experiments (DOE) est souvent utilisée dans le processus « planifier la qualité » afin de déterminer le nombre et le type de tests ainsi que leurs impacts sur le coût de la qualité.

Planifier la qualité

Ce processus consiste en la mise en place d’un plan de contrôle du projet en fonction du type de risque et du niveau de complexité du projet. Il comprend les éléments suivants: Profil projet: le management de la qualité dépend du profil du projet, définit par ce qui suit : Conformité : antitrust, loi Sarbanes-Oxley (SOx), ISO 9000, niveau de classification des informations, normes internationales, etc. Risque : évaluer le risque pour le Business, la complexité de la solution, l’assurance de livraison

du projet. Contrôle et livrables : décrire les points de contrôle et les livrables obligatoires pour le projet. Dans l’exemple cidessous, les points de contrôle sont les Portes d’Etape PE1, PE3 et PE5.

Exemple 68: Livrables Obligatoires et Points de Contrôle

Les autorités de l’Assurance

Qualité du projet : il est nécessaire de définir au préalable les personnes disposant d’un pouvoir de décision et garantes de la qualité des points suivants : Exigences du projet Solution technique du projet Opération et Support à la fin du projet.

Evaluation Revu des des Risques Exige R: Responsible P: Participant Manager de

R

Projet Autorité sur les exigences (garant des exigences) Autorité sur la solution (garant de la solution) Autorité sur la Maintenance & Support Exemple 69: Assurance Qualité - Matrice de responsabilité

Plan de Management de la qualité: il décrit comment effectuer l’assurance qualité durant le projet. Chaque organisation devrait posséder un guide, développé par la

division ou le département qualité, traitant du management de la qualité sur un projet. C’est sur ce guide que le Manager de Projet devrait s’appuyer pour rédiger son plan de management de la qualité de son projet. Il est important que celui-ci soit fiable car il peut permettre de vérifier si le processus de management de la qualité fonctionne correctement. Grâce à un plan de management de la qualité performant, on peut être en mesure de confirmer que les objectifs de qualité d'un projet sont atteints. Les Métriques Qualité : il faut

définir les métriques appropriées selon les normes de qualité du projet pour chaque livrable. La définition est une explication détaillée sur la façon dont on mesure les parties distinctes d'un projet, comme par exemple les dates de début et de fin d'une activité. La mesure de ces métriques, menée dans le processus « mise en œuvre de l’assurance qualité », a pour objectif l’identification des éléments nécessitant des améliorations via des demandes de changement (Change Request). Les Checklists Qualité: à chaque fin de phase, ou à chaque fin d’étape

dans le cas d’une méthodologie comportant les portes d’étapes, il faut toujours dresser une Checklist. Ces listes de contrôle permettront de vérifier que les d'étapes de contrôle qualité ont bien été effectuées.

Exemple 70: Assurance Qualité – Checklist par porte d’étape

Le plan d’amélioration des processus : ce plan décrit les

différentes étapes d’analyse des processus afin d’identifier les activités menant à leurs améliorations. En effet, l'assurance qualité vise à améliorer la valeur des processus et des produits finaux d'un projet. Tout problème rencontré durant l'exécution des activités relatives à l'assurance qualité doit être rectifié. La correction des problèmes peut mener à une amélioration de l'efficacité, à une réduction des coûts de production et à un renforcement de la qualité du produit. Accord et signature des stakeholders: Il est très important

d’obtenir la signature des stakeholders du projet sur le plan de contrôle afin d’éviter tout malentendu. Ainsi, à chaque problème rencontré, il suffirait de consulter ce document afin de trouver la solution adoptée. Il faut également inclure dans le plan de management de projet la façon dont on effectue sa mise à jour. Il est aussi possible que le planning du projet change au cours de son cycle de vie. Par conséquent, les activités de l’assurance qualité peuvent également être amenées à se modifier. Il faut s’assurer que, quel que soit le changement de planning, les personnes signataires en dehors du projet seront toujours en position

d’honorer leurs engagements vis-àvis du plan de contrôle du projet (PCP). Accord sur le Plan de Contrôle du projet (PCP) PCP Nom du Noms des accepté Manager représentants par Qualité du Steering Committee (Comité de pilotage) et du sponsor

Au nom du PMO ou de la personne qui a mandaté le Manager de Projet

Date Exemple 71: Signature et accord sur le Plan de Contrôle du Projet (PCP)

Mettre en œuvre l’assu Ce processus consiste en des audits qualité dont l’un des objectifs est l’identification des éléments nécessitant une amélioration. En effet, ils soulignent l'écart accidentel des objectifs de qualité d'un projet. Quand on effectue les activités d’un projet, il est impératif de faire auditer la qualité du projet, en évaluant le système de management de la qualité du projet. Les audits qualité d'un projet peuvent être annoncés ou non, planifiés ou spontanés. Mais en général l’audit se déroule à chaque porte d’étape afin d’évaluer la qualité livrée par l’étape avant d’entamer la suivante. Ainsi, on

peut introduire une demande de changement pour améliorer le processus, à implémenter durant l’étape suivante. Les audits qualités peuvent être menés par un individu ou par un groupe indépendant. La liste non-exhaustive cidessous décrit les différentes approches possibles pour effectuer l’audit du projet : Une revue par un membre de l’équipe : la revue de la qualité est effectuée par un membre de l’équipe projet, qui possède les compétences requises pour analyser les données de projet, en utilisant les checklists définies au préalable dans le processus « définir la qualité ». Cette approche est souvent utilisée sur un

petit projet à faibles risques. Une revue de la qualité par ses pairs : la revue de la qualité est conduite en face-à-face par un pair extérieur au projet, qui possède les compétences requises pour examiner et évaluer de façon objective les données du projet. Une revue par un panel d’experts : cette revue de la qualité est souvent planifiée et est effectuée de façon périodique. Une revue participative des groupes potentiels de stakeholders : cette revue de la

qualité est souvent élue pour les revues des exigences et des designs de la solution sur des grands projets ou programmes, et dont l’objectif est d’établir de manière efficace un terrain d’entente entre les groupes de stakeholders concernant la solution et la qualité de celle-ci. Une revue par une équipe d’auditeurs indépendants externes : la revue de la qualité est effectuée par des auditeurs indépendants qui ne sont impliqués dans aucun conflit au sein de l'organisation, dans la mesure où cela compromettrait la crédibilité de l'audit. Cette façon d’auditer est

fréquemment observée sur les projets larges, complexes, critiques pour le Business et pour lesquels le steering committee peut ne pas être impartial. Cette approche est souvent effectuée juste avant l’étape d’un investissement lourd à exécuter sur le projet ou juste avant le grand déploiement du projet. Il va de soi que pour qu’un audit soit crédible, ses résultats doivent être mesurés de manière honnête et déontologique et de même, l’auditeur doit avoir traité les données du projet de manière déontologique. Aussi, le Manager de Projet et les membres d'équipe doivent connaître les responsabilités d'un auditeur pour éviter

de s'immiscer dans son travail ou de s’y opposer.

Mettre en œuvre le con Ce processus consiste à dérouler les activités définies dans le Plan de Contrôle du Projet (PCP) qui inclut les métriques et les checklists, afin d’évaluer les performances du projet en matière de qualité et de recommander les modifications nécessaires via le processus de changement de contrôle intégré. Pour ceux qui n’ont pas envie de relire le PCP décrit plus haut, en quelques mots, les activités de ce document comprennent les points suivants :

Assurance Solution qui concerne les activités et les processus conçus pour évaluer la solution et la mitigation des risques d’implémenter cette solution. Vérification qui consiste en la confirmation par inspection que les exigences du projet ont été respectées et que les processus appropriés ont été appliqués. Cette activité répond à la question « le projet a-t-il livré correctement, selon les processus et standard? » Validation qui consiste en la confirmation que les exigences du projet sont alignées sur les besoins et les attentes des stakeholders. Cette

activité répond à la question « le projet a-t-il livré correctement ce qu’on attendait de lui ? »

Management des Ressources Humaines du projet « Qui connait l’autre et se connait, en cent combats ne sera point défait ; qui ne connait l’autre mais se connait, sera vainqueur une fois sur deux ; qui ne connait pas plus l’autre qu’il ne se connait sera toujours défait. » Sun Tzu

Manager un projet demande une articulation claire entre les suivants : Activités nécessaires au projet : le scope et le WBS que l’on a définis ; Le planning : quand et comment vat-on effectuer ces activités ; Les ressources : les personnes mobilisées pour effectuer ces activités. Mieux encore, comment

exécuter ces activités avec le moins de ressources possible car chaque ressource représente un coût à imputer sur le budget du projet. Il s’agit donc d’obtenir le maximum de résultats avec un minimum de ressources, tout en respectant bien sûr les règles du code du travail, car ces ressources sont des hommes et pas des esclaves. On ne les manage pas à partir d’un fichier excel comme si elles ne représentaient qu’un chiffre et un coût sur le projet. Une nuance que certains managers de projet oublient parfois. Les ressources sont plus que des ressources, ce sont des personnes humaines, avec des émotions, défauts et qualités. Le

manager doit se montrer homme ou femme de ressource dans l’art de manager les personnes. On abordera cet art dans la section 5, tandis qu’on se concentrera plutôt, dans les paragraphes ci-dessous, sur la science du management des ressources humaines. Manager les ressources, c’est aussi s’entendre avec elles sur la manière de travailler et de vivre ensemble. L’entente et l’affinité créent des liens de solidarité qui poussent l’un et l’autre à avoir envie de ne ménager aucun effort et de se dépasser pour le projet. Sur un projet, il s’agit d’abord d’acquérir ces ressources que l’on affecte sur les activités du projet. Il

convient ensuite de développer ces ressources pour susciter leur intérêt et leur motivation, non seulement à effectuer ces activités sur le projet, mais également à s’épanouir personnellement pour qu’elles aient l’impression, en sortant du projet, d’avoir acquis une dimension supplémentaire dans leurs compétences et leurs carrières. Enfin, il s’agit également de diriger, suivant un plan de management défini au préalable, ces ressources humaines pour livrer les objectifs du projet. C’est là tout ce en quoi consiste le management des ressources humaines travaillant sur le projet. Le

management

des

ressources

humaines, dans notre contexte de livraison d’un projet, n’a rien à voir avec le management des ressources humaines dans une organisation. On parle ici du management des ressources humaines travaillant sur le projet. Ce domaine de connaissance comprend les processus et les activités qui permettent la planification, le recrutement, le développement et le management de l’équipe de projet.

Figure 35: Management des Ressources Humaines du projet (Source : PMBoK®)

Qui sont ces ressources humaines ? Le management de ressources humaines concerne toutes les ressources humaines qui contribuent au projet :

þ Les membres de l’équipe projet : l’ensemble des personnes qui vont travailler pour livrer les livrables du projet. Le Manager de Projet fait réaliser les activités du projet par l’équipe projet, qu’il faut constituer, développer et, par la suite, manager tout au long du projet. þ Les parties prenantes (Stakeholders) : le sponsor, les clients, les utilisateurs finaux. Le Manager de Projet doit manager les attentes des différentes parties prenantes. On a vu, au début de l’ouvrage, quelles sont les parties prenantes du projet. þ Les ressources en support de

l’équipe projet issues des autres départements fonctionnels de l’organisation : les personnes qui s’occupent de la facturation, qui passent les achats, les juristes, les personnes qui gèrent la logistique ou toutes autres ressources impliquées indirectement sur le projet relevant d’autres départements fonctionnels et dont les coûts ne sont pas imputés au projet. þ Les managers du Manager de Projet, les managers de portfolio et de programme, les cadres supérieurs et dirigeants : les personnes qui s’engagent à supporter le projet et donc à offrir les

ressources nécessaires au projet. Ces personnes ont dû signer la Charte du projet. Un des facteurs d’échec d’un projet est le manque de support et la passivité de ces personnes-là. þ Le Manager de Projet : on oublie souvent que le Manager de Projet doit s’autogérer, prendre sur lui, et doit faire preuve d’automotivation tout en manageant le projet et ses ressources. Ressources virtuelles et multilingues L’équipe virtuelle et multilingue est un phénomène en plein essor et qui se développera de plus en plus. En effet, d’un côté, le business dépasse la frontière nationale et s’effectue

davantage entre plusieurs pays à différents endroits du monde d’où la présence internationale des organisations, et, de l’autre, on remarque l’augmentation croissante de ressources en télétravail. « Virtuel » signifie que les ressources se voient dispersées géographiquement sur plusieurs lieux de travail dans différents pays, voire continents, et ne sont pas basées au siège de la compagnie d’où le projet est managé. Ce fait complique de plus en plus le management de ces ressources par le Manager de Projet. Ressources « Normales » vs « Virtuelles » La différence clé entre une équipe «

normale » et une « virtuelle » se situe au niveau du nombre de face-à-face. Rares sont les situations où l’équipe au complet se situe au même étage, où elle se retrouve à la machine à café, à déjeuner ensemble ou sortir boire un verre pour approfondir la discussion. La communication entre l’équipe projet se fait davantage par le biais de la nouvelle technologie. Les compétences en intelligence émotionnelle du Manager de Projet s’expriment moins car tout se passe en virtuel, plus souvent par e-mail ou conférence téléphonique et, donc, on ne peut pas observer les informations non verbales telles que le langage corporel ou encore les expressions du visage. On ne peut compter que sur le

ton de la voix, le rire qui peut manifester l’enthousiasme de l’autre au téléphone. Des yeux qui brillent, une moue ou n’importe quel mouvement du visage en disaient long auparavant sur les émotions basiques d’une personne comme la joie, la tristesse, la surprise, la peur, l’angoisse, le dégoût, l’intérêt, la confusion, la détermination. En conférence téléphonique ou par e-mail, ce n’est plus le cas. Révolu aussi le temps des réunions où l’on apprécie les beaux sourires qui distraient, les décolletés qui déconcentrent ou encore les joutes verbales yeux dans les yeux. Le charisme d’un Manager de Projet perd un peu de son effet en virtuel.

Management plus complexe des ressources virtuelles Le management des ressources humaines travaillant sur un projet est donc plus complexe quand l’équipe projet est virtuelle, et le nombre de difficultés auxquelles le Manager de Projet doit faire face augmente en conséquence. On peut répertorier, sans être exhaustif, ces difficultés comme suit : Activités : la complexité du projet est moins visible à toute l’équipe virtuelle car chaque membre ne peut voir que sa partie ou une petite partie qui le concerne, d’autant plus que les activités sont des tâches interdépendantes et le fait que l’équipe soit virtuelle rend plus

complexe la façon de faire collaborer ses membres. Le Manager de Projet doit élaborer un plan pour que la coopération sur ces tâches soit la plus efficace possible. Espace : les ressources ne se trouvent pas aux mêmes endroits la plupart du temps sauf quand on organise des réunions en face-à-face ou autre occasion de team-building qui sont rares et coûteuses, car le projet doit supporter le coût du déplacement. Ce manque de proximité, souvent propice à la confiance des ressources, ajoute à la complexité du management. L’équipe est dispersée sur plusieurs sites ou

plusieurs continents, et il est donc difficile d’établir entre coéquipiers la connaissance mutuelle et la fréquentation informelle que cherchent souvent certains membres pour travailler sur la même fréquence. Temps : les ressources ne se trouvent pas dans le même fuseau horaire. Quand il est 14h30 en France, il est 21h30 à Shanghai et il est 7h30 à Chicago. Il est déjà difficile pour le Manager de Projet de trouver un créneau horaire qui convienne à tout le monde pour regrouper l’ensemble des ressources

à la même réunion aux horaires de travail. Si vous ajoutez une ressource se trouvant en Australie, vous vivrez alors un cauchemar dans votre management des ressources car 14h30 en France correspond à minuit et demi le jour d’après à Sidney. En plus de cette complexité engendrée par le fuseau horaire, il y a aussi un impact sur l’équilibre entre la vie privée et personnelle de certaines ressources. En effet, pour une conférence téléphonique à 7h à l’est des US, les ressources de Kuala Lumpur y participent à 20h et le Manager de Projet en France la suit à 14h. Donc, au moins une des

ressources doit assister à la conf en dehors des horaires de travail. Technologie : la collaboration se fait la plupart du temps par le moyen de la nouvelle technologie de l’information et de communication : l’e-mail et le téléphone sont le plus souvent employés et on utilise les télés ou vidéoconférence, l’intranet, Wikis, blogs, facebook internes et autres médias asynchrones et synchrones, comme d’autres outils encore plus sophistiqués pour les organisations qui en ont les moyens (exemple de l’ETC). La disponibilité des outils technologiques et leur

utilisation adéquate par l’équipe sont des facteurs critiques de succès pour une équipe virtuelle. La difficulté est que certaines personnes ne possèdent pas les mêmes outils en fonction de l’endroit où elles se trouvent. Certaines ressources en télétravail ne disposent pas de fax par exemple. Culture : les préférences et la différence de cultures de chaque membre de l’équipe virtuelle compliquent la relation de travail car chacun se présente avec son propre style et sa façon de faire. Le Manager de Projet doit avoir une bonne compréhension du style de chacun en

élaborant son plan de management des ressources humaines. Langue : souvent, la langue de travail choisie est l’anglais, mais chaque membre a un niveau différent dans la maîtrise de cette langue et le niveau lu-écrit-parlé s’interprète différemment selon chaque individu, d’où l’intérêt d’un vocabulaire commun et d’une méthodologie commune de management de projet. Un propos mal formulé ou mal interprété peut générer de graves conflits, que certaines personnes gèrent parfois très mal et qui affectent leurs vies personnelles.

Motivation : comme le dit l’adage « loin des yeux, loin du cœur », un membre de l’équipe peut ne pas se sentir intégré à l’équipe projet. Certaines ressources marchent à l’affectif et si elles ne se sentent pas considérées par leurs camarades, elles ont tendance à se montrer moins performantes. D’autres ressources se sentent isolées et ont l’impression d’être laissées pour compte, ce qui entraîne une baisse de motivation. Pour elles, le pire est l’absence des autres. Il faut faire particulièrement attention aux ressources qui virent dans la paranoïa quand elles ne

reçoivent ni e-mails ou coups de téléphone après quelques heures. Le Manager de Projet doit les suivre particulièrement, les appeler personnellement pour discuter de leurs intérêts sur le projet et à l’extérieur, et les motiver. Le Manager de Projet doit se comporter comme une mère qui veille davantage sur son enfant le plus fragile. Le Manager de Projet doit tenir compte de toutes ces complexités dans son plan de management de ressources humaines, sinon, les risques d’échec du projet s’en voient multipliés.

Elaborer le plan de res

Un Manager de Projet obtient des résultats par l’intermédiaire de son équipe et des stakeholders. Il faut pouvoir tirer le meilleur d’eux, pas en les cravachant mais en les traitant comme des personnes qui feront la différence, qui abattront ensemble et tiendront la distance pour atteindre les objectifs du projet. Pour ce faire, il faut développer une grande et étroite relation de travail, ne pas penser qu’en termes de travail mais plutôt de travail bien fait, les traiter comme on aimerait qu’on nous traite, être capable de tenir compte de l’impact de la « virtualité » de l’équipe projet, et pour cela, soit on les manage au petit bonheur la chance, en espérant que le résultat sera à la hauteur des

espérances du projet, soit on prépare un plan à l’avance pour manager toutes ces ressources. Il y a des managers de projet chanceux qui se trouvent toujours au bon endroit au bon moment avec les bonnes ressources pour livrer les objectifs d’un projet sans recourir à un plan. Mais, pour ceux qui ne veulent pas tout miser sur la chance, il est toujours conseillé de s’appuyer sur un plan de management des ressources humaines qui participeront à votre projet. Il ne s’agit pas de faire un copier-coller d’un plan de management d’un autre projet que vous n’allez même pas appliquer, mais vraiment d’en définir et d’en élaborer un vous-même qui soit personnalisé à vos ressources et à votre projet, en fonction

de sa taille et de son type. Ce plan de management des ressources humaines est un document qui doit être mis à jour tout au long du projet en fonction de l’évolution du projet et de l’équipe projet. Ce document doit faire partie du plan de management du projet élaboré plus tôt (voir exemple). Il sert de guide tout au long du projet sur ce qu’on a l’intention de faire avec les ressources, à savoir comment les acquérir et avec quelles compétences, comment les développer et, enfin, surtout comment les diriger.

Plan de Management des Re

La Matrice de responsabilité (RACI) Un projet est comme un sport colle

Projet, et l’équipe est représentée pa savoir qui joue à quel poste. Il fau Responsabilités tout en décrivant les le reporting et la durée de l’interven s’assurer que les rôles soient bien dé l’équipe comprenne son importance Nom Rôl Raymond Ma Myriam Lea William Lea Fatima Lea Thierry PM Rama Stee Jean-Pierre Stee

Les compétences et connaissances re Il faut documenter les compéte travailler sur le projet. Il faut fai savoir-faire requis par le projet par p

Intégration de l’équipe Kick-off : La réunion de kick ressources qui seront impliquées sur

Team-building : il s’agit de déf pour les activités de teambuilding. U est le fait que ses ressources humain plaisir à le faire. Même si l’équipe créer, maintenir et dynamiser la sy tous ensemble au pub ou au res l’approche associe les activités de loi

Plan de formation : il est n déterminer les besoins en formations l’équipe projet – et les planifier. organiser : formation virtuelle à dist via du coaching ou un apprentissage entame déjà sa tâche. Par exemple, celle abordant les technologies de l’in

l’équipe va devoir utiliser tout au embauche les managers de projets, produits de l’organisation ne pourra de Projet et pour l’organisation elle-m

Les lieux géographiques et les condit Décrire où se trouvera le siège du Décrire les localités géographiques Définir la fréquence des déplace documenter même les membres qu autres pour se déplacer ; Définir les besoins en termes de dé Décrire où se trouvent la war ro facilités utilisées pendant le projet ; Définir les horaires de trav compensation pour les heures travail Documenter les périodes où les co se passe à un moment critique du pr Décrire le plan de back-up d’une r Décrire les processus de demande

doit être conforme à celui de l’org travaille sur le projet, le Manager l’approbation de la demande de cong Plan d’acquisition des ressources Les besoins de ressources par p en termes de ressources en fonctio intégralité par période (phase, étape) période pour éviter tout ''gaspillage' que ne soit attribuée à chaque a nécessaire à sa réalisation. Mode d’acquisition : décrire le en interne d’un autre département, localité géographique ou en externe, projet, etc. Processus d’acquisition de la re on va acquérir cette ressource e impliquées pour ce faire. Par exemp définitivement sur le projet ou la co le temps du projet ? Remplacement de ressource

exposé à la Loi de la chaise vide, procédures de remplacement de ress on ne peut rien contre les turn-ove membres de projet qu’il va fallo équivalentes de mêmes qualification ressource pour mauvaise performa mettre en place une procédure pour

Évaluation de la performance et Réc Évaluation de la performance : l'évaluation de la performance de c évalué et mesuré, et à quelle fréque évaluation concerne tous les memb externe ou interne. Récompense : décrire le mod performance de chacun des membre primes, bonus, formation, une poign récompense quand la ressource perf partie concerne les membres de l’é externes doivent être récompensés p

Exemple 72 : Plan de Management des Ressources Humaines

Ce plan de management des ressources du projet doit être validé par tous les stakeholders et le Manager de Projet doit disposer du support de ses cadres dirigeants et de son organisation pour son implémentation durant le projet. Au risque de me répéter, l’un des facteurs d’échec d’un projet est le manque de support et la passivité de l’organisation. Si le plan de management des ressources humaines est bien défini, alors il devient très facile de dérouler tous les autres processus comme constituer, développer ou encore diriger les ressources

humaines. En revanche, si le plan est mal défini, le Manager de Projet court un grand risque de ne savoir que faire lorsqu’une situation non prévue par le plan de management des ressources humaines ce déclenche, demandant du manager qu’il ou elle improvise, laissant encore une fois le résultat aux mains du hasard.

Constituer l’équipe de Dans ce processus, il s’agit d’appliquer ce qui a été défini dans le document de plan de management des ressources humaines ci-dessus, notamment la partie acquisition des ressources pour une phase ou étape du projet pour certaines ressources et pour

d’autres jusqu’à la fin du projet. Il faut s’assurer alors d'avoir les ressources adéquates en nombre et en qualification. Ressource Interne Toute entreprise en avance sur la méthodologie de management de projet doit disposer d’une base de données des ressources dans laquelle on peut trouver au minimum les compétences, les connaissances, le savoir-faire ainsi que la disponibilité de ces ressources. Les ressources internes sont issues de l’organisation et empruntées aux différentes unités fonctionnelles. Bien que les ressources empruntées rendent compte au Manager de Projet tout au long du projet, les chefs restent leurs

chefs dans leurs entités respectives. En effet, autrefois on appelait le Manager de Projet « chef » de projet, car son autorité était directement assimilée à sa force hiérarchique et bureaucratique. Toutes les ressources humaines travaillant sur le projet étaient alors sous ses ordres directs. Aujourd'hui, dans la matrice d’organisation composite où l’équipe est empruntée à différentes entités, chaque ressource empruntée relève de deux responsables, l’un fonctionnel métier et l’autre opérationnel. Les ressources qui travaillent à temps partiel sur le projet ajoutent une dimension complexe à la tâche du Manager de Projet, surtout celle

de faire prévaloir sa priorité sur cette ressource partagée. Aujourd’hui, l'autorité du « chef » est assimilée à sa capacité à négocier et à déléguer auprès des acteurs. Il fait dès lors davantage de management que par le passé. Le PMO peut aider en cas de litige sur la priorisation d’une ressource à travailler sur un projet plus que sur un autre. Ressource Externe En général, on se tourne vers les ressources externes pour les raisons suivantes : La ressource n’existe pas en interne : quand l’organisation ne trouve pas, dans sa base de données, de ressources avec les compétences

et le savoir-faire requis ; La ressource n’est pas disponible en interne : quand les ressources aux compétences et savoir-faire requis se trouvent déjà occupées par d’autres projets et dans l’impossibilité de quitter ces projets en cours ; La ressource est disponible en interne mais se trouve dans une autre ville, pays ou continent où le projet doit se dérouler : sur certains projets, il vaut mieux constituer des équipes locales, à savoir toutes les ressources sont présentes sur le lieu où se déroule le projet, afin de

diminuer la complexité du management de ces ressources virtuelles ainsi que la difficulté à livrer les livrables du projet à distance. Ceci constitue donc un choix stratégique. Dans ce cas, les ressources humaines sont des prestataires de services venant de sociétés de service ou des indépendants. Ces ressources peuvent aussi être fournies par les partenaires locaux de l’organisation le temps du projet. Nous verrons en détails l’acquisition de ces ressources dans le paragraphe sur le domaine des connaissances sur les approvisionnements.

Développer l’équipe d Dans ce processus, il s’agit d’implémenter ce qui a été défini au préalable dans le document de Plan de Management des Ressources Humaines, pour que l’équipe apprécie de collaborer ensemble sur le projet, qu’elle améliore ses compétences et se développe professionnellement comme personnellement sur ledit projet. Dans la culture chinoise, le chef ne développe pas les compétences de son équipe, ce qui est une source de démotivation. Il existe plusieurs façons de

développer l’équipe projet, dont notamment les suivantes : Teambuilding: il faut développer l’alchimie, cette interaction d’une personnalité avec une autre, car les ressources sont amenées à vivre une aventure commune : le projet à réaliser. Une équipe qui s’entend et qui communique bien travaille plus facilement et a tendance à livrer des résultats extraordinaires. Un bon état d’esprit engendre la performance. Quand l’alchimie existe, elle transforme les membres de l’équipe projet, même les plus ordinaires, en de véritables winners. En revanche, quand l’alchimie ne prend pas, elle change les membres de l’équipe, même

les ressources les plus talentueuses, en losers. Les activités de teambuilding, préalablement définies, aident le Manager de Projet à constamment développer et maintenir la synergie et la dynamique de groupe tout au long du projet. Mentoring : faire bénéficier d’un mentor à certaines ressources ne peut qu’améliorer la chance de succès du projet tout en développant la ressource elle-même. Certains managers de projet senior peuvent venir encadrer et coacher un junior pour livrer proprement son projet par exemple. Formation : il faut former les

ressources aux connaissances que le projet nécessite, mais également leur offrir des formations qu’elles pourront utiliser plus tard sur un autre projet, ce qui peut constituer pour elles une source de motivation. La formation contribue au développement de la ressource. Style de travail et préférences des ressources : il faut constamment sensibiliser les ressources sur la différence entre les cultures, les préférences et le style de travail de chacune des ressources. Il faut toujours améliorer et développer les conditions de travail de chaque ressource sur le projet.

Encore une fois, on ne peut pas improviser cette partie, il faut la définir au préalable dans le document de Plan de Management des Ressources Humaines.

Diriger l’équipe de pro Manager les ressources en fonction du planning Pour exécuter le planning, il faut diriger les ressources afin qu’elles exécutent leurs tâches respectives dans les délais impartis. Pour contrôler un planning, il faut également contrôler les ressources. L'un des moyens de contrôle des ressources consiste à gérer leur taux d'utilisation. Le taux d'utilisation des ressources désigne la quantité totale de

travail attribuée à chacune d’elles. Le Manager de Projet doit planifier soigneusement les activités afin de ne pas surcharger les ressources. Certaines ressources participent à l’intégralité du projet, d’autres sont appelées le temps d’une phase, d’une étape ou, tout simplement, d’une activité. Les ressources peuvent varier du tout au tout au fil du projet, et ceci peut entraîner une baisse de productivité et une mauvaise utilisation des ressources auxquelles le Manager de Projet doit faire attention. Par exemple, retirer des ressources d’une activité afin de les répartir plus uniformément sur le projet peut allonger la durée de l’activité et, par conséquent, la durée totale et

augmenter le coût du projet. Manager la motivation de l’équipe et l’effet d’accélération finale On a tous connu nos 24 heures chrono où tous les membres du projet travaillent ensemble jour et nuit, non pas pour sauver le monde d’un désastre imminent comme Jack Bauer dans la série, mais juste pour livrer le projet à temps. On a tous connu avec l’équipe projet et les stakeholders cet effet d’accélération finale, à savoir cet élan, cette énergie ou encore ce dynamisme particulier qui nous habite et nous mobilise quand on se rapproche de la fin d’une phase, d’une étape ou du projet. Idéalement le Manager de Projet devrait

pouvoir donner le même élan et créer le même dynamisme au quotidien pour garder ses troupes motivées, et leur moral au beau fixe tout au long du projet. Mais il est difficile de maintenir cet effet d’accélération finale jusqu’au bout. Comme on l’a vu plus tôt, le projet connaîtra des hauts et des bas et il faut garder à l’esprit que la joie vient toujours après la peine. Des outils qui restent très populaires pour manager la motivation des ressources sur un projet sont les suivants : Incitation positive : un bonus, une prime, au minimum une tape sur l’épaule par exemple, quand la

performance de la ressource est bonne sur le projet ; Incitation négative : mise à l’écart du projet, par exemple, quand la performance de la ressource ne correspond pas aux attentes sur le projet. Le Manager de Projet peut considérer également les suivants : Un management participatif : offrir aux membres de l’équipe la possibilité de donner leurs avis sur le projet, de participer à la prise de décision, au choix de la stratégie – faut-il arrêter le projet ou pas ?par exemple. L’idée n’est pas de

rallier l’équipe à sa décision, pour mieux se dédouaner plus tard parce qu’on n’a pas envie de porter seul la responsabilité d’une décision risquée, quand on n’est pas sûr du résultat, car cette décision nous appartient. Par contre ce projet est aussi le leur, ils ont un avis à donner sur le sujet, les faire participer aux décisions est chose normale. Il faut les faire participer à tout pour maximiser et réunir les conditions du succès ou la construction de la solution. Ainsi, le membre du projet a l’impression d’exister et ne doit pas s’excuser d’exister parce qu’il s’est mêlé aux

prises de décisions. Un bon Manager de Projet sait écouter les avis, les préconisations et ne ressent pas cela comme une honte ou un signe de faiblesse. Il doit savoir encourager l’esprit de challenge en incitant son équipe à participer à tout. L’empowerment: encourager son équipe à se responsabiliser et à prendre plus d’initiative, à s’investir davantage dans le projet sans la blâmer si elle échoue. Le Manager de Projet se met au service de l’homme de terrain, celui ou celle qui exécute les

activités et s’engage à tout lui fournir, les meilleurs outils, le meilleur environnement. Le Manager de Projet doit développer un climat qui autorise la prise de risque en leur faisant confiance. Ce n’est pas une incivilité que de laisser l’autre s’exprimer et émettre de meilleures idées que soi. Il faut valoriser ses apports et ses prises d’initiatives, pour que l’autre ne devienne pas l’ennemi du manager du projet si ses idées ou opinions diffèrent des siennes. Faire l’éloge de son équipe : le Manager de Projet doit reconnaître

publiquement, en l’exprimant haut et fort, le travail bien fait, et savoir récompenser par les incentives positives, par exemple. Il faut louer et promouvoir l’équipe au sein de l’organisation, et dire à quel point cette équipe est dévouée et performante. Il faut éviter de laver le linge sale de l’équipe en public et, surtout, d’ébruiter des rumeurs ou des jugements sur tel ou tel autre membre de l’équipe. Développement personnel : Manager de Projet doit garantir développement personnel de ressource et surtout éviter de

le le la la

garder sur le projet contre son gré. Il doit aider au développement de ses ressources et est en retour en droit de demander l’implication totale de la ressource sur le projet. Le Manager de Projet doit s’engager à tenir sa promesse et doit surtout éviter de lancer des paroles en l’air. Le Manager de Projet se doit de trouver les moyens de transmettre du savoir-faire et de passer du temps à développer leurs compétences et leur vision. Bannir le micro-management : un Manager de Projet doit éviter tout micro-management de la part

du management de projet. Il n’y a rien qui démotive plus une ressource qu’un Manager de Projet qui s’implique davantage dans ses tâches, contrôlant tout et prenant des microdécisions en lieu et place des intéressés. J’ai même rencontré des managers de projet qui finissaient par effectuer les tâches des membres de l’équipe projet. Il faut laisser son équipe innover et faire preuve de créativité car, sinon, il y aura une baisse d’implication du membre, engendrant une baisse de motivation.

Le soutien moral à tout moment : le Manager de Projet ne doit pas donner à son équipe l’impression qu’il la néglige, surtout à celle dont les membres sont distants, en télétravail, en remote. Les appeler individuellement de temps en temps, en dehors des réunions en groupe, pour discuter de tout et rien, leur prouvera qu’on ne les oublie pas. Il est aussi possible de définir une charte sur la motivation et de la distribuer à tous les membres de l’équipe projet.

Une charte sur la motivation distrib Wenger, surnommé le professeur Outre son équipe de football. (Source : The Gua L’Équipe:

Une équipe est aussi f La force motrice d'une équip créer et maintenir d'excellentes r peut ajouter une dimension sup dynamique d'équipe. Cette attitude peut être utilisée sur la reconnaissance et les ava l’équipe apporte à nos propres renforcer et approfondir les relati attendent une équipe forte et unie Notre équipe devient forte :

En affichant une attitude positiv En laissant tout le monde l'équipe

En ayant la conviction inébr notre objectif En croyant en la force de l'équi En voulant toujours plus – en d En se focalisant sur notre comm En étant exigeant avec nous-mê En étant frais et dispos pour ga En mettant l'accent sur le fa persévérant jusqu'à la fin En croyant à notre identité qua jouant le jeu que nous aimons jou En se serrant les coudes En restant les pieds sur terre e tant que personnes En affichant le désir de gagner En profitant de la chance qui n équipe et en y apportant notre co acquis Exemple 73 : Charte de motivation d’une équipe

Manager les conflits avec les ressources toxiques « On ne devrait jamais tourner le dos à un danger pour tenter de le fuir. Si vous le faites, vous le multiplierez par deux. Mais si vous l'affrontez rapidement et sans vous dérober, vous le réduirez de moitié. » Winston Churchill Tout le monde compte sur le Manager de Projet pour livrer un projet avec succès, et cela passe par des ressources performantes qui travaillent efficacement. Mais le chemin emprunté par un projet n’est pas souvent parsemé

de roses : il arrive que des conflits éclatent entre des membres de l’équipe projet, entre stakeholders ou encore entre le Manager de Projet et un membre de l’équipe ou des stakeholders. Un bon Manager de Projet ne se dégonfle pas, fait face aux conflits et se doit de trouver des solutions. Il gère les crises qui peuvent survenir entre les personnes au jour le jour et n’attend pas que les problèmes se résolvent d’euxmêmes avec le temps, car la situation peut empirer. Selon le philosophe Michel Serres, une crise est un passage entre l’ordre et le désordre. Le Manager de Projet passe son temps à imposer une structure et de l’ordre à son management

dans lequel un conflit peut survenir et tout chambouler. Les conflits restent une période difficile, parfois très difficile pour le Manager de Projet amené à résoudre de nombreuses contradictions sans nuire à ses relations avec l’ensemble des ressources impliquées, et surtout sans empirer la situation. Parfois, dans ces moments de crise, le rôle de Manager de Projet peut s’avérer intenable. Un livre ne suffit pas et ce n’est d’ailleurs pas l’objectif de cet ouvrage : il faut une formation et du vécu pour devenir expert du management de conflit. Ne vous découragez pas pour autant, les quelques lignes ci-dessous

donnent quelques pistes pour manager les crises. Pour ce faire, le meilleur moyen est de se montrer proactif et de percevoir les signes avant-coureurs, les flairer et prévenir leur développement. Le pire est d’attendre et de se convaincre qu’avec le temps, tout s’arrangera. Plus on attend, plus la situation peut empirer. Sur un projet, les sources de conflits peuvent être nombreuses mais les suivantes sont récurrentes à tout projet : Une ressource toxique : toute personne dont les actions ou inactions volontairement négatives ont une influence et un impact négatifs sur le progrès du projet est

toxique et peut polluer l’atmosphère du projet. Les signes sont souvent : Attitude je m’en-foutiste : la ressource zappe les conférences téléphoniques, ne répond jamais au téléphone, livre le minimum, se montre indifférente au sort du projet ; Critique : la ressource distribue des mots très durs comme des critiques destructives à l’endroit du projet et de ses membres, elle se montre très agressive, s’auto-manage et pense qu’elle sait tout ; Refus de l’autorité : la ressource refuse les ordres du

Manager de Projet en invoquant qu’il n’est pas son chef ; Ressource qui n’est pas à sa place : la ressource a été assignée contre son gré à des activités sur le projet, elle traîne les pieds, rêve d’une vie meilleure ailleurs et surtout pas sur ce projet-là. Certaines personnes passent leur vie à se dire qu’elles seraient mieux ailleurs sur des projets à venir ou encore sur tous ceux sur lesquels elles ont travaillé. Rien ne les satisfait jamais ; Conflit entre des membres de l’équipe projet : une des ressources ébranle la cohésion de

l’équipe projet. Ces gens peuvent perturber le bien-être de l’équipe ; La surcharge de travail d’une ressource : la ressource peut ne pas avoir de comportements toxiques mais est tout simplement débordée ; elle preste, par exemple, 80 heures au lieu des 35h dans la semaine. Et, dans ce cas, le problème peut venir du Manager de Projet car ce dernier ne sait pas allouer ni le temps ni la durée des activités pour son équipe projet… Le Manager de Projet est responsable du travail fourni par cette personne sur son projet et se

doit de résoudre perturbatrice.

son

attitude

Conflit d’affectation de la ressource : une ressource qui travaille à temps partiel sur le projet peut être une source de conflit avec les autres managers de projet qui utilisent cette même ressource sur leurs projets. Il y a souvent un problème de priorisation de la ressource. On a beau faire des plannings, on sait qu’il peut y avoir un changement de dernière minute venant tout chambouler et demandant l’apport d’une ressource déjà réservée à un autre projet, où son

absence peut retarder les deux projets qui impliquent la même ressource. On a beau planifier, ce sont des choses qui arrivent ; Conflit d’intérêts entre stakeholders : on a vu que les parties prenantes sur un projet peuvent toutes avoir des attentes différentes. Chacun va donc défendre ses intérêts personnels et cela peut dégénérer en situations conflictuelles quand les attentes ne convergent pas. La loi de la chaise vide : la ressource clé du projet part au mauvais moment. Ceci peut avoir un

impact dévastateur sur le projet car ce départ peut mettre en péril le résultat.

Loi de la chaise vide l’équipe projet quitte so du projet. Loi 3 : Chaise vide

Approche pour résoudre les conflits « L’individu qui ne s’intéresse pas à ses semblables est celui qui rencontre le plus de difficultés dans l’existence et nuit le plus aux autres » Alfred Adler L’une des difficultés d’un Manager de Projet est de résoudre les conflits : un Manager de Projet dépend de ses ressources pour effectuer les travaux du

projet, et il suffit que l’une ou plusieurs d’entre elles ne livrent pas ce qu’on attend d’elles et c’est le conflit assuré. Afin de résoudre ces conflits au quotidien, on peut penser, en respectant l’ordre donné, à l’approche suivante : 1. Remise en cause : le Manager de Projet doit d’abord se remettre en cause car le problème peut venir de lui. En effet, il peut être à la source du problème et des comportements conflictuels affichés par des membres ou des stakeholders. Il devrait donc commencer par évaluer s’il agit correctement, en n’hésitant pas à demander leurs avis aux personnes concernées. Si c’est le

cas, c’est aussi se montrer professionnel que de reconnaître ses erreurs et d’envisager de se corriger par la suite. Dans le cas contraire, donc si le Manager de Projet est fautif, il faut alors prévoir un entretien, téléphonique d’abord, et si cela empire, un face-à-face. 2. Entretien : le Manager de Projet doit avoir un entretien individuel avec la personne avec qui le conflit existe. Il devrait avoir lieu dans un cadre neutre, pas dans les couloirs sur le chemin de la cantine, et pas à n’importe quelle heure ni à la vavite, cela ne doit pas être un coup de téléphone juste avant de quitter le

travail. Il faut toujours envoyer une demande de réunion à une heure qui convienne aux deux parties en mentionnant spécifiquement l’objet de la réunion qui n’est rien moins que discuter du conflit. Au cours de cet entretien, on demande à cette personne ce qui ne va pas, ce qu’on peut envisager de faire ensemble pour que les choses aillent mieux. Il ne s’agit pas là de paroles en l’air, il faut établir un plan d’action avec la personne. 3. Tierce personne : si les choses ne s’améliorent pas, il faut impliquer une tierce personne, le manager de la ressource si c’est un conflit causé

par une ressource, le steering committee pour arbitrer et trancher s’il s’agit de conflits d’intérêts de stakeholders, etc. En Chine, les conflits se règlent à l’amiable : on ne peut pas louer la rapidité de la justice chinoise mais, en revanche, on peut applaudir leur approche par la médiation via une tierce personne pour résoudre les conflits. 4. Escalade : si les choses ne s’améliorent vraiment pas, il faut monter très haut dans la hiérarchie afin de trouver une solution acceptable pour tout le monde. Certains managers de projet ont peur de cette escalade pour diverses

raisons : ils pensent jouer au « bad cop », ils ne veulent pas créer de problème à la ressource à l’origine du conflit ou encore ils craignent le jugement de ces personnes plus haut placées qui pourraient penser qu’ils manquent de compétences pour régler eux-mêmes le conflit. Il ne faut jamais hésiter à s’en remettre à la hiérarchie qui dispose d’une plus grande autorité pour résoudre un conflit. Comme un projet ne se fait pas sans conflit, il ne faut pas hésiter, en début de projet, à définir les chartes de bonne conduite ou une charte de management de conflit que l’on fait lire à toutes les

ressources impliquées sur le projet. Charte de Management des co Je vais :

Considérer les opportunités de développem

Chercher à comprendre des parties impliquées av des solutions ;

Choisir le moment opport du sujet du conflit ;

Écouter ouvertement d'au

Répéter à l'autre personne si c’est correct ;

Reconnaître les points val

Exprimer nos points de jugement ni d’une façon ag Chercher à trouver un ter Exemple 74 : Règle de base de management de conflits

Management des réunions avec les ressources Un Manager de Projet passe sa vie en réunion s’il le veut, mais il devrait en limiter le nombre afin de mettre en place les actions décidées entre deux réunions. Les réunions se font souvent sous la forme de conférences téléphoniques ou vidéoconférences avec une équipe virtuelle, ce qui rend les réunions encore

plus complexes car il manque le face-àface, permettant d’évaluer la communication non-verbale de l’autre, à savoir sa posture, ses mouvements, son regard, son décolleté, etc. Et, surtout, on ne sait pas si l’interlocuteur à l’autre bout du monde fait semblant d’écouter et vaque à d’autres choses pendant la réunion au lieu de participer de façon active. J’ai personnellement surpris des participants à des réunions virtuelles à chatter sur des sites de rencontres. Communication verbale et paraverbale Durant ces réunions, le Manager de Projet ne peut donc compter que sur sa communication verbale avec ses mots et

sa prose, ou encore sur sa communication para-verbale en jouant sur le ton et le volume de sa voix ainsi que le rythme de ses paroles afin de ne pas rendre monotone la réunion. Ainsi, il doit donc stimuler la participation active et l’engagement des ressources pour que ces réunions soient pertinentes et efficaces. Afin de faciliter ces réunions, le Manager de Projet peut définir à l’avance des guides et des procédures pour les réunions et recueillir l’accord de tout le monde pour que tous adhère à l’esprit de ces guides et procédures (voir exemple).

Guide et procédure pou

1. Les 2. 3. 4. 5. 6. 7. 8.

réunions en face-à-fac _________Jours/Semaines/Mois. Les réunions en visio ou téléc _________Jours/Semaines/Mois. L’invitation pour les réunions se Projet. L’ordre sera envoyé ____jour(s)/ ___. La réunion est présidée à tour de de l’équipe. Le compte-rendu de réunion se différents membres de l’équipe. Le compte-rendu de la réunion d la réunion. On a le droit de rectifier le com sinon tout silence est considéré rendu. Qui ne dit mot consent.

9. La réunion doit commencer 10. 11.

12. 13. 14. 15.

16.

retardataires. Chaque membre de l’équipe doit v Il est demandé à chaque membre d’arrêter toute autre activité e virtuelles. L’agenda de la prochaine réunion Les sujets à discuter offline seron la réunion. Les problèmes que l’on n’a pas seront ajoutés dans le fichier log d Les participants qui ne peuvent envoyer leurs points de vue l’organisateur de la réunion, o prendra les actions et les décisions Les réunions ne sont pas le théâ compétitions pour les idées les p

faire avancer le projet ensemble Exemple 75 : Guide et Procédure de réunion

Quelques règles de base pour une réunion réussie Enfin, pour des réunions efficaces, tout Manager de Projet doit prendre en compte les quelques règles de base cidessous : Ordre du jour : il faut toujours soumettre un ordre du jour sur les points à discuter, les décisions à prendre, le suivi des progrès des actions en cours, les actions à venir, etc. Cela aide les participants à se préparer à l’avance. N’organisez que des réunions utiles où les gens ne

parlent pas pour ne rien dire et qui ne s’éternisent pas ; Réunion participative : la méthode de papa consistant à ne faire parler que le Manager de Projet pendant que le reste écoute est révolue. On n’est pas dans un style de leadership paternaliste où tout va à sens unique. L’équipe reconnaît la compétence mais pas l’autorité. Il faut inciter les participants à la réunion à s’exprimer, un débat doit avoir lieu, les points chauds doivent être discutés, et il faut éviter de verser dans la tendance française (selon les Hollandais, du temps où je

travaillais aux Pays-Bas) : on parle beaucoup, on écoute peu et, surtout, on ne décide de rien. Une réunion durant laquelle tout le monde participe peut souder l’équipe ; Réunion ouverte à toute idée ou initiative : il faut s’ouvrir et écouter les opinions de chacun, il faut accepter l’esprit de challenge de son équipe ou des stakeholders sans s’énerver et verser dans une réaction émotionnelle. Il ne faut pas craindre les critiques car, lorsqu’on entreprend quelque chose, on est d’office exposé à la critique. La réunion est le lieu indiqué pour ce

faire et non pas à l’extérieur ni dans le dos de la personne concernée. Support de réunions : il faut des slides ou un autre document écrit partagé en ligne avec l’ensemble des participants. Non seulement, cela aide à la concentration des participants mais également à la compréhension du message à véhiculer pendant la réunion, surtout pour ceux qui ne connaissent pas suffisamment la langue employée. Un dessin ne vaut-il pas des milliers des mots ? Les comptes-rendus de réunion :

il faut rédiger les actions, les décisions et distribuer le compterendu à tout le monde. En cas de litige ultérieur, on pourra toujours se référer à ce compte-rendu. FUN : il est important de créer une bonne atmosphère dans laquelle les participants peuvent s’amuser tout en travaillant, de ne pas organiser de réunions monotones où les gens ne prennent pas de plaisir à venir et à participer. N’hésitez pas à vous former à la technique d’animation de groupe si vous n’êtes pas à l’aise pour être la chaire des réunions. Même si certaines personnes les

regardent bizarrement et ne les prennent pas au sérieux, les personnes joviales ne sont pas forcément des charlots. Ce sont aussi des professionnels qui, contrairement aux coincés, peuvent exprimer des choses sérieuses et saignantes avec le sourire. Évaluer la performance de son équipe Manager des ressources, c’est aussi les évaluer, leur fournir un feedback de leurs performances aussi bien sur les activités dont elles s’occupent que sur leurs attitudes, ou encore les points à améliorer comme les points forts. Le Manager de Projet évalue la performance de chaque membre de

l’équipe projet et fait du management en conséquence en prenant des actions préventives ou correctives. Le membre de l’équipe évalué peut apprendre de cette évaluation et en tirer les conséquences appropriées. L'évaluation continue, périodique ou épisodique est nécessaire pour une amélioration de la performance. On procède à cette évaluation aussi bien sur les internes que sur les externes car on veut améliorer la performance de tout le monde sur le projet. Il est hallucinant de voir que certaines compagnies n’évaluent pas du tout la performance des externes sur leurs projets, comme si cela les laissait indifférentes et satisfaites, quelle que

soit la performance. Ne pas stimuler la performance d’une ressource peut avoir un impact direct sur sa motivation car, quels que soient ses efforts, elle sera toujours une ressource externe et pour certaines organisations, les ressources externes sont considérées comme des personnes de seconde zone. Certains managers de projet devraient se renseigner sur l’effet pygmalion sur une équipe de projet.

Effet Pygmalion : Pygmali une statue représentant une la vie. Dans l’enseignement, il est prouvé que la perform subordonné dépendent de ce Si l’attente est forte, les performances suiven

Loi 4 : Effet Pygmalion

Les internes, les responsables des ressources humaines, ainsi que le manager de la ressource impliquée sur le projet ont souvent besoin de l’input du Manager de Projet pour évaluer la performance et les mérites du membre du projet, et cela joue souvent sur le développement de leur carrière. Ce n’est pas le propos de ce livre de décrire en détails l’évaluation de la performance, et la littérature est déjà inondée d’ouvrages sur le sujet, mais il est bon de rappeler qu’il faut juste que le Manager de Projet soit capable de mettre en place un dispositif d’évaluation fondé sur des éléments

objectifs. Manager la notion de plaisir sur un projet « Jamais les cœurs sensibles n’aimèrent les plaisirs bruyants, vain et stérile Bonheur des gens qui ne sentent rien et qui croient qu’étourdir sa vie c’est en jouir. » Jean-Jacques Rousseau Plus que toute autre chose, c’est la notion de plaisir qui constitue la clé de la réussite. On a vu que l’état d’esprit engendre la performance. La notion de bien-être d’une ressource est un facteur de succès pour le projet. Quand une ressource prend du plaisir à travailler

sur le projet, cela ne peut lui être que bénéfique : on avance plus facilement même s’il faut franchir des murs immenses, et cela conduit forcément à de meilleurs bénéfices et une rentabilité améliorée. Cette ressource va servir de bon ambassadeur et va promouvoir le projet. Bien évidemment, tout le monde n’a pas la même conception du plaisir. Pour certains, le plaisir vient après l’effort, pour d’autres, le plaisir s’atteint en même temps que l’effort comme travailler en chantant par exemple. Pour un bon Manager de Projet, le plaisir consiste à privilégier l’homme par rapport à la ressource. Voir l’homme

s’épanouir sur son projet est une source de plaisir. Il n’y a pas non plus de plaisir plus grand pour le Manager de Projet que de voir son équipe comprendre et valider ses idées, comme partager sa façon de faire. Un très bon Manager de Projet sait cultiver cette notion de plaisir quand les ressources viennent travailler sur son projet sans bouder ni traîner la patte.

Figure 36: Joie d'un Manager de Projet jouant

au golf avec son équipe projet

Chacun peut concevoir ses notions de donner aussi du plaisir à ceux qui travaillent sur son projet ; on rencontre souvent les comportements suivants: Laisser les choses se faire naturellement ; Acquérir un nombre suffisant de ressources pour que toutes puissent jouir d’un équilibre décent entre vie professionnelle et vie privée, et cela parfois au détriment d’un coût plus élevé du projet. On essaie souvent de dépenser moins en tirant le maximum des ressources qu’on a à notre disposition ; Développer et maintenir un

environnement qui encourage le progrès et le développement personnel de chacun et qui réduit le stress ; Éviter la culture du blâme, les cris, les engueulades : chacun a droit à l’erreur ; Renforcer l’esprit d’équipe en dehors du bureau - des sorties ad hoc à l’improviste, quelques bières dans un pub en regardant un bon match de rugby ne font pas de mal -, assurer la petite ambiance, faciliter les connaissances mutuelles et la confiance. Organiser occasionnellement des déjeuners ou des dîners d’équipe : ce

ne sera pas le grand soir, mais juste manger, boire ensemble et partager d’autres choses que le travail. Cela peut souder l’équipe et libérer certaines tensions. En Chine, le dîner est mieux vu car plus informel, plus détendu, les pintes se descendent facilement et cela peut avoir un effet cathartique sur un groupe qui ne se voit pas souvent. Su Rester honnête et intègre vis-à-vis de son équipe de projet. Cette notion est développée plus tard (Page 117). La réputation d’un Manager de Projet se mesure au succès de son projet mais aussi à son management des ressources humaines qui ont travaillé sur son projet.

Le Manager de Projet ne doit pas oublier que ce sont ces mêmes ressources qui vont répandre sa réputation. Les managers de projet jouissant d’une bonne réputation n’ont aucun mal à attirer et à garder les ressources douées de talents sur leur projet. Manager les ressources, c’est aussi s’assurer de s’entendre avec elles. Une impression positive et durable dépend du type de relations que l’on a entretenues avec elles. Il est important que cela colle entre le Manager de Projet et chacune de ses ressources car il lui serait sinon très difficile d’obtenir quelque chose d’une personne qui ne l’apprécie pas forcément et qui se trouve

juste sur le projet par obligation.

Management des Communications du projet « Il y a un moment où les âmes se touchent et savent tout sans qu’on ait besoin de remuer les lèvres. » Maeterlinck

Tous les acteurs du projet vont peu ou prou participer, contribuer et assister aux mêmes événements du projet, mais en fonction de leurs intérêts et points de vue respectifs. En effet, chacun percevra différemment les événements. La communication sur les

évènements du projet et autour d’eux est l’aspect le plus crucial du management de projet. Le domaine des connaissances sur le management des communications recouvre l’organisation interne et externe en matière de communication sur le projet. C’est-à-dire la manière dont les acteurs doivent communiquer, les canaux à utiliser et la fréquence de ces communications. Ce domaine de connaissance comprend les processus et les activités qui permettent la génération appropriée et en temps voulu des informations du projet, ainsi que leurs archivage, diffusion, stockage et déclassement définitif. En effet, la communication comprend également la

documentation, que certains managers de projet abhorrent car ils la considèrent comme un fardeau administratif. Il est vrai que cela demande un effort substantiel, mais si le Manager de Projet est organisé et ne documente que ce qui est nécessaire pour le projet, cette étape peut devenir une routine. Il faut éviter de tomber dans le piège d’alourdir le processus de management par des documents qui ne servent pas au projet. Les PMOs offrent un guide sur la méthodologie et les templates à utiliser sur les projets, mais il revient au Manager de Projet de n’utiliser que ce qui est utile à son projet.

Figure 37: Management des Communications du projet

La communication à l’instinct, sur le plan de l’échange de contenu, peut atteindre ses limites lorsque le nombre d’interlocuteurs est important. Il devient

alors difficile de prendre connaissance des demandes de chaque membre de l’équipe et de chaque stakeholder et de les concilier, sachant que pour un groupe de N personnes, le nombre de communications ou relations possibles est de :

Sur un projet, un Manager de Projet, en plus de son équipe projet, peut interfacer avec plusieurs acteurs comme démontré dans le schéma ci-dessous :

Exemple 76: Interface d'un Manager de Projet

Cette communication est d’autant plus difficile lorsque la relation est virtuelle. Il est donc important d’identifier les personnes avec qui le Manager de Projet doit communiquer et de planifier par la suite le type de message (rapport sur l’état d’avancement, rapport sur les Earned Value, rapport pour le steering committee, etc), la fréquence de la communication entre ces personnes et enfin, les canaux de communication (Web, e-mail, téléphone, SMS, vidéo, Facebook du projet, etc.) En termes de canal de communication, l’utilisation des médias sociaux (Facebook du projet par exemple) est grandissante. Quelque

chose a changé dans le monde du travail: des médias sociaux sont utilisés depuis longtemps pour communiquer avec les clients. Mais aujourd’hui, nous avons la possibilité d’utiliser ces outils de communication pour travailler sur nos projets et avec nos équipes de projets. Le Manager de Projet doit également être en mesure de traiter des informations telles que les documents de leçons apprises, les archives du projet, le contrat avec le client, les présentations et rapports générés tout au long du projet et les feedbacks des stakeholders, qui sont autant de communications.

Identifier les stakeholders

prenantes Après « pourquoi lancer un projet ? », la question que tout Manager de Projet doit se poser est la suivante : quelles sont les parties prenantes? Quels sont leurs objectifs ? Quel est l’impact de ce projet pour elles ? Quelles sont leurs attentes ? S’il faut identifier de façon exhaustive les stakeholders, c’est parce que le succès de tout projet repose entièrement sur le degré d’implication et la force de l’engagement des personnes qui sont amenées à y contribuer, et même de celles qui sont silencieuses mais ont quelque intérêt dans les résultats du projet. Ces personnes sont les

stakeholders du projet. Elles peuvent être internes ou externes à la compagnie et leur influence en début de projet est considérable. Nous avons vu dans la section 2 que dans un environnement de projet de plus en plus complexe, une bonne compréhension des stakeholders du projet est cruciale. Il convient évidemment de les identifier, mais un très bon Manager de Projet devrait également déterminer les stakeholders hostiles (qui auront un impact négatif sur le projet), les alliés du projet (qui le défendront bec et ongles et lui seront bénéfiques), les décideurs (qui ont un grand pouvoir d’influence sur le projet)

ou les détenteurs d’informations les plus pertinentes capables de contribuer à la réussite du projet.

L’une des techniques d’identification repose sur l’élaboration d’une liste par catégories de stakeholders qui ont besoin d’informations sur le projet, comme le montre le tableau ci-dessous : Groupe de Stakeholders Validation des livrables

Description: Toute personne qui examine et valide les livrables Les personnes qui managent

Nom(s): C D

Projets dépendants

d’autres projets pouvant être impactés par ce projet Toute personne Impactés par impactée les résultats directement par le résultat de ce projet Toute personne directement impliquée Contributeur dans ce projet (par exemple, l’équipe projet)

Responsable de la réalisation

Fournisseur, intégrateur, etc.

Sponsor

Toute personne comptable et responsable de la réalisation du projet Les groupes ou personnes externes nécessaires à la mise en œuvre du projet Le groupe ou la personne qui va sponsoriser le projet

Propriétaire ou exploitant

Utilisateurs

Les personnes qui vont prendre en charge la responsabilité du résultat du projet (par exemple, le service support et maintenance) Les personnes qui vont être amenées à utiliser le résultat du

projet Etc. Exemple 77: Identification de Stakeholders

Planifier les communicatio Lorsque les stakeholders ont été tous identifiés, il faut élaborer un plan de communication avec eux, qui définit les éléments suivants : Les exigences des stakeholders : définition des besoins en termes d’information et de communication de chacun des stakeholders. Pour ce faire, le Manager de Projet devra conduire une analyse des exigences des stakeholders en termes de communications. Quel stakeholder veut quelle information?

Les attentes des stakeholders : comme nous l’avons vu dans la section 2, il faut analyser les attentes des stakeholders du projet et ce que le projet attend d’eux. Les types de messages : le Manager de Projet doit préparer et identifier les informations à communiquer aux différents groupes de stakeholders, lors des différentes phases du projet. Il existe trois types d’information de base orientés sur : 1. Le projet : information générale sur le projet tel que l’état d’avancement, les risques, les problèmes, les changements, etc. 2. Les processus : implémentation

de processus pour la diffusion d’informations particulières à chaque groupe spécifique de stakeholders (voir par exemple le processus pour le steering committee) 3. Analyse des stakeholders : information qui répond spécifiquement aux besoins de chaque stakeholder. Responsabilité : définition claire des rôles et responsabilités imputés aux personnes en charge de la création des notes de communication et du rapport d’avancement. Ceux-ci seront ensuite distribués aux différents stakeholders.

Récepteurs de l’information : recensement des stakeholders pour chaque liste de diffusion pour les différents types de communication sur le projet. Canaux de communication : il existe plusieurs méthodes pour partager l’information, qui varient en fonction des destinataires et du contenu de l’information. Il faut veiller à ce qu’il y ait un mélange de communication dans les deux sens et déterminer le canal de communication par catégorie de stakeholders et par type d’information. Par exemple, on peut archiver les présentations faites au

steering committee sur le portail du site web du projet et envoyer le lien à tous les stakeholders par e-mail. Un autre exemple est la définition sur un projet des canaux de communication à utiliser comme suit : Canal Site Web du projet (intranet)

Message/Contenu News sur le projet, annonce, calendrier, événements, charte d’organisation, la matrice RACI, archive des documents du projet, etc.

Récep Equipe projet

Stakeh

Employ intéress par le p

E-newsletters Une communication à de l’organisation sens unique sur le projet: vision et impact du projet dans l’organisation. Magazine spécialisé, journaux papier ou télévisés Evénement groupe

Tous le employ l’organ

Informations sur le Le gran projet diffusé au public grand public.

Vision et impact du projet dans

Tous le employ

l’organisation.

Posters

Sensibilisation, partage d’informations clés sur le projet.

Tous le employ l’endro le poste affiché

Brochures / Tracts dépliants prospectus

Conseils et astuces Les sur les utilisate informations clés à connaitre

Email (sortant)

Boîte email fonctionnelle du projet

concernant un projet. News relatives au projet, annonces, événements, réponses aux commentaires ou autres demandes. Demande d’actions, de ressources, d’informations relatives au projet. Peut être utilisé pour organiser des réunions ou des événements. Réception des réponses aux demandes

Groupe spécifiq

Tous le membr l’équip

(e-mail entrant)

d’information, suggestions des employés, réponses à différentes études sur le projet. Demande d’informations issues du site web du projet.

projet

Demo (faceà-face)

Le résultat complet ou en partie du projet.

Client

SMS

Demande urgente d’informations.

Équipe projet

Exemple 78: Canaux de communication

Fréquence de communication : il convient de renseigner dans le document de plan de communication la fréquence des communications. Type

Canaux

Fréquence

Kick off

Face-à-face

Une fois le 1 avril Toutes les tr semaines le mardi de 9h 16h GMT Hebdomada Mardi de 14 16h GMT Tous les premiers jeu

Discussion Design

Face-à-face

Vidéoconférence

Discussion Service

Face-à-face

du mois de 9 16h GMT

Vidéoconférence

Bihebdomad Mercredi de 14h à 16h GMT

Face-à-face

Tous les premiers lun du mois de 9 16h GMT

Email

Hebdomada en fin de semaine

Progrès du projet

Discussion Face-à-face générale

Tous les deu mois Lundi de 9h 16h GMT

Face-à-face

Tous les derniers jeud du mois de 9 12h GMT

Vidéoconférence

Nécessaire à chaque fois

Comité de pilotage

Exemple 79: Fréquence de communication sur un projet

Processus d’escalades : il faut également documenter la façon dont on procède aux escalades, et qui en

fait le suivi. Mis à jour du plan de communication : enfin, il convient de définir dans le plan de communication le processus de sa mise à jour. Par exemple, on ne devrait pas disposer du même plan de communication en temps de « crise » qu’en temps « normal ». Nous avons vu que le projet traverse des eaux troubles par moment où la communication doit être plus fréquente que d’habitude. On peut également, par exemple, définir un plan de communication différent d’une phase à une autre.

Diffuser les informations Il s’agit maintenant de rendre l’information disponible, selon les délais déterminés, aux différentes parties prenantes identifiées, chacune recevant le type d’information définie plus tôt dans le plan de communication.

Exemple 80: Diffusion de la communication

Si le document du plan de management de la communication est bien rédigé, cette partie se déroulera parfaitement. Sinon, il s’agira d’improviser tout au long du projet, ce qui peut être vu comme un manque de professionnalisme de la part du Manager de Projet. Cela peut déboucher sur un conflit avec certaines parties prenantes qui risquent de se plaindre du manque d’informations sur le projet. Le Manager de Projet doit s’assurer que l’information distribuée est claire et complète, que le destinataire la reçoit correctement par le canal de communication défini auparavant et que

le contenu est compréhensible. Bien entendu, la méthode de distribution des informations doit être définie au préalable et customisée en fonction du destinataire. N’hésitez pas à utiliser les templates prédéfinis par les PMOs pour les différents rapports à envoyer.

Manager les attentes o stakeholders La communication avec les parties prenantes est un élément important, voire essentiel dans le management de projet. Un bon Manager de Projet se doit de mettre en place une ligne de communication avec toutes les parties prenantes, ainsi qu’un mécanisme permettant de garder les stakeholders impliqués et toujours au courant de l’état d’avancement des projets. Le Manager de Projet doit manager de façon active les attentes préalablement déterminées des

stakeholders, en communiquant et en travaillant avec eux afin de les satisfaire au mieux. Pour ce faire, le Manager de Projet peut s’appuyer sur les fichiers de log suivants : Actions Log : liste des attentes des stakeholders traduites en un certain nombre d’actions à mener. Problèmes Log : liste des problèmes survenus lors de l’exécution du projet et dont la non-résolution peut avoir un impact négatif sur le projet. Changements Log : changements survenus lors de l’exécution du projet. Un changement peut avoir une

conséquence faste ou néfaste par rapport aux attentes d’un stakeholder sur un autre. Ces fichiers de log doivent être mis à jour et monitorés de façon proactive. Le Manager de Projet doit s’assurer de résoudre toutes les difficultés. Car les problèmes nonrésolus peuvent se transformer en source de conflits et de retard pour le projet. Un bon management des attentes des stakeholders augmente considérablement la chance de réussite d’un projet.

Rendre compte de la pe Pour surveiller et contrôler

proprement l’exécution du projet, il faut également mettre en place un rapport mensuel de performance, pour évaluer si le projet peut toujours livrer les valeurs pour lesquelles il a été lancé, et faire du management en fonction. Le comité de pilotage (steering committee) a besoin de ce rapport pour jouer pleinement son rôle de pilotage du projet, et les stakeholders en ont besoin également pour savoir où en est le projet. Dans ce rapport, on devrait voir apparaître au moins les éléments suivants : Un bilan de santé générale du projet : certains l’appellent aussi KPI (Key Performance Indicator) ou ICP (Indicateurs Clés de Performance). Grâce à un indicateur ( , , ), on

devrait disposer de l’état global du projet.

Bilan de santé générale du

De sérieux problèmes affecte impact significatif sur sa réalis plans d’actions correctives so dépend le retour au vert ( ).

Des problèmes et des risques s du projet et peuvent avoir un i Les actions correctives et le

place, et le retour au vert ( ) dé

Le projet se déroule dans les qu’il existe des risques et des p ne peuvent en aucun cas a réalisation du projet .

Exemple 81: Rapport - Bilan de santé générale du projet

La santé globale du projet dépend des paramètres suivants : Niveau de confiance et de certitude pour livrer le projet (haut , moyen , bas ) : il faut réellement se demander si l’on est toujours confiant quant à la réalisation des objectifs du projet. Il faut s’appuyer sur des faits et non pas sur une intuition. Gouvernance du projet(active , partielle , inexistante ) : il faut évaluer si une structure de gouvernance effective et claire est

en place et si elle fonctionne de façon active en définissant les directions à prendre et en manageant de façon efficace les problèmes et les risques susceptibles de nuire au projet. Plan de réalisation des bénéfices(atteignable , difficilement atteignable , inatteignable ) : il faut mesurer si le projet peut toujours réaliser un ROI positif comme défini dans le Business Case. Dépendance du projet(sous contrôle , problèmes mineurs avec un risque très grand , problèmes

significatifs ) : il faut évaluer si les dépendances externes au projet sont sous contrôle ou si elles peuvent avoir un impact significatif sur la réalisation du projet. Ressources du projet : (disponibles et compétentes , problèmes mineurs avec un risque très

grand , en sous-effectif ou

manque de compétence ) : il faut évaluer si le projet est en souseffectif ou en sureffectif, si les ressources disposent des bonnes compétences, nécessitent des formations ou encore manquent des compétences requises pour réaliser les objectifs du projet.

Scope(stable , problèmes mineurs avec un risque très grand , problème significatif ) : il faut évaluer si le scope est stable et si le processus d’intégration du changement de scope fonctionne de façon effective. Un rapport sur l’échéancier du projet: chaque Manager de Projet doit être capable de mesurer si son projet prend du retard ou de l’avance par rapport à la planification initiale. On peut calculer, par exemple, le Schedule Variance (Écart de délai) en pourcentage entre la durée totale du projet initialement prévue et la durée totale du projet réestimée à l’instant du

rapport. Nous verrons cette partie dans les détails dans le paragraphe sur les outils et techniques.

Bilan de l’échéancier du projet Projet représentant un retard irrécupérable : le projet représente un retard de plus de 20% par rapport à la référence initiale de l’échéancier (schedule baseline), et ce retard n’est plus récupérable : il nécessite une réinitialisation du projet et son impact sur le business est critique. Exemple: le projet d’avion de transport militaire polyvalent conçu par Airbus (Airbus A400M), où la France devait recevoir son premier A400M au

bout de 77 mois, soit le 31 octobre 2009. Des difficultés techniques et politiques ont retardé le programme, qui suite à quoi la France n’aura son premier avion en service qu’entre 2012 et 2013, soit 4 ans ou 208 semaines plus tard (SV= 170%). (Source : Wikipedia) Projet représentant un retard récupérable : le projet représente un retard entre 5% et 20% par rapport à la référence initiale de l’échéancier (schedule baseline), mais il est toutefois récupérable. Exemple: la durée initiale du projet est de 50 jours, et la durée

réestimée avant le rapport est de 58 jours : la SV vaut donc 16%. Projet dans les délais : le projet est légèrement en avance ou en retard par rapport à la référence initiale de l’échéancier (schedule baseline). Exemple: la durée initiale du projet est de 50 jours, et la durée réestimée avant le rapport est de 52 jours : la SV vaut alors 4%. Exemple 82: Rapport - Bilan de l’échéancier du projet

Un rapport sur le budget du projet : chaque Manager de Projet doit être capable de mesurer le coût déjà dépensé et estimer le budget des

travaux restant à faire par rapport à la planification initiale. On peut calculer, par exemple, le Cost Variance (Écart de coût) en pourcentage entre le coût total du projet initialement prévu et le coût total du projet réestimé à l’instant du rapport. Nous verrons cette partie dans les détails dans le paragraphe sur les outils et techniques, notamment la technique des Earned Values (Valeurs acquises).

Bilan sur le budget du pro

Projet représentant une déviation représente un surcoût significatif par (cost baseline). Ce surcoût n’est demande de refinancement du proje

Exemple: le coût du programme

programme, à un total de 20 milli l'été 2009, à 25 milliards d'euros, p 2010 (+ 7,7 milliards, soit PricewaterhouseCoopers (PWC) av mener à bien le programme (sans 31,3 milliards d'euros.

Projet représentant un surcoût r surcoût par rapport à la référence i est toutefois récupérable.

Projet dans les budgets : le co impartis du projet par rapport à baseline). Exemple 83: Rapport sur le budget du projet

Management des Risques du projet

« Seuls ceux qui prennent le risque d'éch spectaculairement réussiront brillammen Robert Fitzgerald Kennedy

Avant d’aborder le management des risques, il faut avant tout s’entendre sur la notion de risque. Pour cela, il faut présenter les mêmes défauts et des

qualités différentes ou encore partager la même définition des choses. Pour certains, l’incertitude sur les retours sur investissement est un risque, car on s’expose à la perte de l’investissement. Par exemple, on court le risque de perdre un investissement immobilier à une époque où la demande faiblit car le marché s’effondre pour cause de crise économique (le credit crunch). Pour d’autres, le risque est une indication sur la grande probabilité d’une conséquence négative sérieuse d’un événement. Par exemple, un escalier sans rampe est perçu comme dangereux : dans certaines organisations, il est obligatoire de la tenir car le risque d’une chute peut être

fatal. Pour d’autres encore, tout événement futur ou une condition pouvant empêcher le projet d’atteindre ses objectifs est un risque.

Risque : événemen concrétisation aurait u objectifs du projet. (P Définition 14 : Risque

Sur un projet, le « risque » est quelque chose qui menace la capacité du Manager de Projet à maintenir l’intégrité d’un ou de plusieurs paramètres du projet qu’il a promis de livrer. Par exemple, le Manager de Projet a promis de livrer des résultats à une certaine date, mais à cause d’événements imprévus indépendants de sa volonté, il

n’est pas en mesure de tenir ses promesses. Autre exemple : le Manager de Projet ne maintient pas un environnement sain au sein de l’équipe projet, qui court le risque de se détériorer à tout moment car l’environnement dépend de la culture et de la façon de faire de chacun. Plus le Manager de Projet dispose d’informations sur la culture et la façon de faire de chacun, plus il réduit le risque que l’ambiance se dégrade.

Figure 38: Risque - Information vs Incertitude

On peut donc dire que le risque est une mesure de l’incertitude autour d’un événement ou d’une condition. Par incertitude, j’entends absence

d’information, de connaissance ou de compréhension du résultat, de l’effet, des conséquences d’une décision ou d’un événement. Moins on dispose d’information, plus l’incertitude est totale et donc plus grand est le risque. Plus on dispose d’information, plus on a de certitude et moins grand est le risque (Figure 38: Risque - Information vs Incertitude). Les incertitudes peuvent se décliner comme suit : Les connues (Knowns) : c’est une position ou un événement qui ne comprend aucune incertitude. On sait que cela va arriver. Par exemple, on sait qu’on éprouvera moins de

douleur quand on arrêtera de se frapper la tête contre un mur. Les inconnues (Unknowns) : c’est une position ou un événement dont on connaît l’existence mais dont on ne peut savoir comment elles vont heurter le projet. Par exemple, un cyclone dont on connaît les forces mais dont on ne peut prévoir comment il touchera la ville. Les connues-inconnues (Knownunknowns) : c’est une incertitude que l’on peut identifier. Par exemple, en travaillant dur, le Manager de Projet peut s’attendre à une

augmentation de salaire, mais on ne sait pas à quel moment ni quel sera le montant de l’augmentation. Un autre exemple est le tremblement de terre : on sait qu’il existe mais on ne sait pas comment il peut affecter Haïti ou la Nouvelle-Zélande. Les inconnues-inconnues (Unknown-unknowns): ce sont des positions ou des événements dont on ne peut pas imaginer l’existence. Le SIDA avant que la maladie ne soit découverte, par exemple, ou encore le Mediator, ce pseudo-médicament qui a déjà tué des milliers de personnes qui, à la base, ne

connaissaient que les propriétés curatives du médicament et ne soupçonnaient pas son effet mortel. Un autre exemple est l'accident nucléaire de Fukushima à la suite du tremblement de terre et tsunami du 11 mars 2011. Le risque lié au séisme et au tsunami avait été pris en compte, mais si, pour le séisme, ces dispositions étaient suffisantes, elles ne l'ont pas été pour le niveau d'eau induit par le tsunami. Cela imposera sûrement réexamens des risques unknowns-unknowns sur les autres centrales japonaises. Le management des risques peut être différencié des managements de

problèmes (Issues), car les problèmes sont déjà existants et le projet est en train d’en subir les conséquences. Les risques, par contre, sont susceptibles de causer des problèmes lorsque les événements ou les conditions, qui n’étaient que des menaces pour le projet au départ, se cristallisent en problèmes. Le domaine de connaissance sur le management des risques du projet comprend les processus et les activités qui permettent de planifier, d’identifier, d’analyser et de maîtriser les risques du projet.

Figure 39: Management des Risques du projet

Le management des risques est une approche pour anticiper et traiter les événements, qui peuvent causer une déviation significative du projet de ses objectifs. Le management des risques est

une activité qui doit être effectuée tout au long du projet. Le Manager de Projet se doit de rendre régulièrement compte de ces risques à chaque réunion d’équipe projet ou avec le steering commitee.

Planifier le Manageme Le document de Plan de Management des Risques (PMR) susceptibles de heurter le projet doit établir la manière d’aborder les risques tout au long du projet, et planifier les activités de management de ces risques. Le Manager de Projet, en collaboration avec l’équipe projet, les stakeholders, le sponsor, le steering committee et les experts amenés à travailler sur le projet, doivent contribuer à la mise en place de ce document de Plan de Management des Risques. Je rappelle que chaque projet

est unique : chaque document sur le Plan de Management des Risques doit donc être personnalisé et rédigé en fonction du type, de la priorité ou de l’importance du projet pour l’organisation. En effet, deux projets de même type mais d’une importance ou d’un degré de criticité différent, ne courent pas les mêmes risques. Par exemple, construire un stade de football sans la contrainte de l’organisation d’une Coupe du monde exigeant de finir le stade avant le début du Mondial présente un risque de retard moindre qu’une construction sous contrainte de temps.

Plan de Management des Risques

Définition Afin d’éviter les confus commune de ce que comporte le manag la définition et la signification précisém va travailler et pour lequel le Plan de M

Risque : il est reconnu comme avoir un effet potentiellement n succès du projet tels que, par ex de l’infrastructure du réseau ou e Business Partenaires, la fiabilité d distinct des problèmes qui se so sont déterminés au niveau de l’éq

Plan d’actions de mitigat risques ont été identifiés et prior pour les manager. Pour chaque r être élaboré. Ce document doit

préventives qui peuvent réduire, produire. Lors de l’élaboration de dépendances entre les risques ou examinées. Il faut éviter de rédu l’amplifier dans un autre. Un plusieurs risques identifiés.

Plan de contingence : le mesures réactives à mettre en œ risque que l’on ne peut pas éviter plusieurs plans de contingence d mis en œuvre si le risque se produ être définis par l’ensemble de l’éq

Probabilité d’occurrence : identifié de se transformer en ré peut être classé comme suit : Échelle

Probabilité

Cri

L’é

8

Presque certain

4

Probable

2

Possible

1

Incertain

atte

Il e pos Il y l’év Il l’év

Afin de déterminer le montant risque, le Manager de Projet doit calcul de probabilité.

Impact : Il faut mesurer le n facteurs de succès du projet.

Échelle

Impact

Critère

8

Critique

4

Majeur

2

Moyen

1

Mineur

Tous le menacé Presque projet s Quelqu pourron On peu risque

Afin de déterminer le montant risque, le Manager de Projet d financier.

Le facteur du risque : le nivea de la probabilité et de l’impact d déterminer le niveau du risque identifiés dans le but de concen traiter le risque. Le niveau du risq

Facteur de Risque = P

Le Fichier de Risque Lo comprendre les risques identifiés mitigations des risques et les Manager de Projet est responsab que la mise à jour du PMR.

Manager le niveau et la priorisation Le management et la priorité à donner p fonction du niveau de risque comme su Critique Le comité de directio Le Steering Committ

en mettant en place p mitigation ainsi que le

Majeur Le Steering Committ Le Manager de Proje mettant en place puis mitigation ainsi que le

Moyen Le Manager de Proje mettant en place puis mitigation ainsi que le

Mineur L’équipe projet prend

Processus de Management des risque

Figure 40: Processus de

Le processus suivant doit être suivi t

1. Identifier les risques : à chaque

projet et les stakeholders do brainstorming pour identifier le mettre en travers du projet en u animée par le Manager de Pro projet peuvent y être invités. À to membre de l’équipe projet ou sta tout risque potentiel au Manager d

2. Analyser & Évaluer le risque

Steering Committee ou le Manag le niveau de risque associé. En Steering Committee ou le Mana pour traiter le risque.

3. Répondre au risque : la ress

soumettre un plan d’actions de Manager de Projet ou au Steeri valider la proposition de plan.

4. Documenter le risque : le Manage

fichier Log des risques, chaque ri chacun d’entre eux.

5. Contrôler et surveiller le risque : l

un suivi des états de chaque risqu jour le niveau de risque et la répo Exemple 84: Plan de Management des Risques

Ce document de Plan Management des Risques (PMR) doit être mis à jour tout au long du projet par le Manager de Projet. Il doit être distribué à tous les membres de l’équipe qui doivent consentir à l’utiliser au fil du projet, s’y référant à chaque fois qu’il s’agira de

traiter des risques.

Identifier les Risques Au début de tout projet, il faut identifier tous les problèmes potentiels qui peuvent mettre à mal le projet et, surtout, il ne faut pas oublier de documenter leurs caractéristiques. Cet exercice qui consiste à balayer le spectre des risques est à réaliser avec l’ensemble de l’équipe projet et avec les stakeholders. Il ne faut pas hésiter à convier tout expert pouvant contribuer à la session d’identification des risques. Ce processus est itératif, on peut identifier les risques tout au long du projet, avec l’équipe projet également,

qui remonte les risques en suivant le processus décrit dans le plan de management des risques. Il faut bien identifier autant les risques « isolés », que les risques « non-isolés ». Les risques isolés sont ceux qui se produisent durant une phase et qui n’ont d’impact que sur cette phase du cycle du projet. Les risques non-isolés sont ceux qui ont un impact sur plusieurs phases ou sur tout le projet. Afin d’identifier les risques, il existe plusieurs techniques : on peut faire appel, par exemple, à des techniques comme le brainstorming ou encore la technique Delphi. Afin de mieux stimuler la pensée ou la

créativité des participants, on peut utiliser un support en partant, par exemple, des éléments suivants : La frontière du scope du projet : les suppositions faites pour définir le scope, les dépendances avec d’autres projets ou ressources et les contraintes du projet ; Les leçons apprises des projets précédents du même type : dans une organisation dotée d’une culture du management de projet, ce genre d’information est disponible et riche d’enseignement, surtout par rapport à ce qui s’est mal passé dans un autre projet similaire ; Checklist : il ne faut pas hésiter à

se servir d’une checklist également. En effet, l’une des techniques d’identification des risques consiste à utiliser des checklists. Il faut utiliser la checklist conçue pour le type de projet que l’on veut réaliser. Si cette checklist n’existe pas, rien n’empêche le Manager de Projet et son équipe, ainsi que les stakeholders, d’en élaborer une, propre à leur projet. Les différents types de checklist Checklist 1 - Les domaines typiques où les incertitudes sont élevées : afin d’identifier les problèmes potentiels, il faut considérer le projet dans sa globalité et la relation entre les sources

typiques de risques et les objectifs du projet : Scope : l’étendue et la définition des activités, les omissions ou les erreurs de design, le changement de scope ; Délai : l’estimation de la durée du projet et des activités, la date de fin de projet imposée ; Coût : l’estimation des coûts, le coût du support et de maintenance, un budget limité ; Technologie : l’attente du client, la probabilité de succès, la capacité d’évoluer, le succès du design ; Ressources : la qualité, la quantité, la disponibilité, la

compétence, la définition des rôles et responsabilités ; Organisation : la priorité et les connaissances de l’organisation, la coordination entre différents départements ; Commercialisation : le volume de vente, le prix, les attentes des utilisateurs, la probabilité de succès commercial, la qualité ; Facteurs externes : la régulation, les actions ou réactions des concurrents. Checklist 2 - Les problèmes potentiels spécifiques : dans le cas où votre organisation possède une liste préexistante de tous les problèmes

potentiels spécifiques, collectés auprès de projets de même type, alors, si votre projet s’en rapproche, il vous faut prendre tous les documents déjà produits sur votre projet (la charte du projet, le scope, le WBS, le budget, etc.) et vérifier pour chacun d’entre eux si un ou plusieurs des problèmes mentionnés dans la liste préexistante sont susceptibles de se produire sur votre projet. Ce genre de checklist existe dans les organisations qui ont une vraie culture de management de projet. Checklist 3 - Les risques autour du planning : dans l’environnement de projet de nos jours, une attention incroyablement démesurée est donnée au

planning. Ce type de checklist ne se focalise que sur les positions ou événements qui peuvent avoir un impact sur le planning : Le développement de l’échéancier du planning : La date de fin est dictée par le management ou par le désir de faire plaisir à certains stakeholders, ce qui a pour impact un planning irréaliste et irréalisable ; Certaines activités peuvent manquer également car on a surestimé les ressources clés ; L’équipe qui a fait le planning est différente de celle qui exécute

le planning ; Le planning a été réalisé pour un certain groupe qui n’est plus disponible ; La deadline irréaliste ne sert qu’à démotiver l’équipe projet ; Etc. ; Problèmes client : Changements des exigences du client ou incessant changement de scope ; Les revues, les décisions, les communications effectuées Le client ne s’engage pas avant que les choses ne se matérialisent ; Le client est « trop » impliqué ;

Imposition d’une contrainte non nécessaire ou irréaliste ; L’infrastructure fournie par le client est de mauvaise qualité ; Le client a des attentes irréalistes en termes de délai ; Etc. ; Problèmes interpersonnels : Une mauvaise relation au mieux ou, au pire, une relation conflictuelle entre les membres de l’équipe projet ; Les membres de l’équipe projet n’ont ni foi ni passion pour le projet ; Les membres de l’équipe projet ne sont pas réellement motivés à

travailler sur le projet ; Certains membres de l’équipe projet tardent à monter en compétences sur le projet ; Certaines ressources clés se retirent en cours du projet ; Les ressources critiques ne sont pas disponibles au moment où le projet en a grandement besoin ; La responsabilité assumée par un membre du projet est trop grande pour ses compétences ou le costume à porter pour une grande responsabilité est un peu large pour la ressource ; Problèmes de management et de politiques :

Le management impose beaucoup de restrictions ou d’ordres à l’équipe projet ; Le management de la part du sponsor et de l’exécutif est inexistant ; Réduction des ressources imposée par le management ; La revue et les décisions du management prennent plus de temps que prévu ; Les décisions du management ne motivent pas l’équipe ; Implication trop tardive de la partie prenante pour la maintenance et le support ; Les activités « non core » du

projet telles que la logistique, le légal, le dédouanement ont un impact sur le projet ; Etc. Quelle que soit la technique utilisée, il est primordial d’identifier les risques et de documenter leurs caractéristiques. Courir le risque de ne pas le faire revient un peu à naviguer en pleine mer sans boussole ni matériel de sauvetage en ne comptant que sur son sens marin. C’était un peu l’approche de papa que l’on essaie d’éviter en suivant une méthodologie avec des processus bien définis.

Mettre en œuvre l’ana

L’analyse qualitative consiste à prioriser les risques en les évaluant. Cette activité de classification des risques par ordre de priorité est essentielle car on peut ainsi vraiment concentrer les efforts sur les risques les plus menaçants pour le succès du projet. Tous les risques n’ont pas les mêmes niveaux d’importance : il faut trouver une façon de les déterminer et de les classifier par ordre d’importance. Il va de soi que les risques les plus importants ont une priorité plus grande. Il y a plusieurs façons de faire, de la plus simple à la plus compliquée selon votre style de management de projet. On verra dans ce paragraphe,

deux approches pour classifier les risques par ordre de priorité. Analyse de niveau des risques par la probabilité et l’impact Impact Quand un risque est identifié, il faut réaliser une évaluation de la signification de ce risque. Une des mesures pour l’évaluer est son impact, ou effet, qui se traduit typiquement par un coût additionnel si le risque est amené à se produire. On peut exprimer l’impact des risques en termes financiers, notamment le coût de l’effet. Il y a souvent trois éléments à considérer dans son évaluation :

Délai : l’impact sur le planning pour livrer le projet et le coût de cet impact ; Performance : impact sur la performance technique du résultat attendu ; Image : impact financier sur la relation avec le client pour le business en cours et pour le futur ; et impact sur l’image du projet sur le marché. Par exemple, le fait que Toyota rappelle plus de 400.000 voitures à cause d’un système de freinage instable a causé du tort à ce constructeur d’automobile. Chaque organisation détermine, en fonction de son type de projet, sa propre

définition des impacts. Une des façons est de les définir comme suit : Impact 5 : Sévère 4 : Majeur 3 : Modéré 2 : Mineur 1 : Trivial

Perte de Profit De 85 à100% De 50 à 84% De 21 à 49% De 5 à 20% Moins de 4%

Augmentatio Coûts Plus de 50

De 30% à 5

De 10% à 2

De 5% à 9 Moins de 4

Exemple 85 : Définition d'impact des risques

Probabilité (%) Un risque est, de par sa nature, aléatoire mais on peut toutefois lui associer une

probabilité d’occurrence. L’autre mesure utilisée pour déterminer le niveau de risque est donc la probabilité que le risque se produise. On peut l’exprimer en pourcentage ou en description (très certaine, probable, incertaine, etc.) qui reflète la possibilité du risque de se produire. Des questions typiques pour aider à l’évaluation de la probabilité des risques incluent les suivantes : Quels étaient les risques dans un projet similaire ? Combien de fois ce risque s’est-il produit dans les autres projets similaires ? Quels sont généralement les risques dans ce domaine de

business ? Combien de fois ces risques s’étaient-ils produits dans ce domaine de business ? Quand on calcule la probabilité d’un risque, il est important d’éviter de prendre en compte les mesures qui ont déjà été mises en place pour minimiser la possibilité du risque de se produire ou pour réduire son effet. La probabilité du risque doit être considérée comme la possibilité d’apparition sans que des mesures spéciales de prévention soient déjà mises en place. Chaque organisation détermine, en fonction de son type de projet, sa propre définition des probabilités. Une des

façons est de les définir comme suit : Classement Probabilité 5

% Probabilité

Probabilité d’occurrence

Plus de 85%

Presque certaine

2

De 50% à Probable 85% De 21% à Possible 49% De 1% à 20% Peu probable

1

Moins de 1% Improbable

4 3

Exemple 86 : Définition des probabilités des risques

Niveau de risque Une des façons de classifier le niveau

des risques est de combiner la probabilité d’occurrence des risques avec leur impact sur le projet comme suit : Niveau de Risque = Probabilité x Impact

Une fois que la probabilité et l’impact de chaque risque ont été estimés, on peut alors procéder à une classification par niveau de risques. On peut, par exemple, utiliser une Matrice d’évaluation des risques en utilisant des indicateurs d’état ( , , ) comme suit :

Probabilit

X 1

1

2

3

2

Impact

3 4 5

Exemple 87 : Matrice d'évaluation des risques

Ou le niveau des risques peut, par exemple, être défini comme suit : Inacceptable ( ) : le risque doit être réduit par une technique de transfert de risques ; Indésirable ( ) : le risque doit être réduit par une technique de

mitigation. Un plan d’action préventive détaillé et une analyse des impacts sont requis ; Acceptable ( ) : le risque peut être traité par une technique d’acceptation mais il faut surveiller la moindre aggravation. Les activités normales d’amélioration continuelle doivent s’appliquer. Le coût d’implémentation d’une mesure préventive peut être plus grand que le coût d’occurrence du risque. Dans ce cas, on accepte le risque. Un risque avec une probabilité faible d’occurrence est d’un niveau acceptable pour le projet sauf si son impact est extrêmement sévère pour le projet. De

même, un risque avec un faible impact est aussi d’un niveau acceptable pour le projet. Chaque niveau de risque doit être réévalué régulièrement car la probabilité d’occurrence ainsi que son impact peuvent changer au cours du projet. Analyse de niveau des risques par le score et l’impact Dans cette analyse qualitative, la classification des risques peut se faire également par le calcul de l’impact du risque et du score par catégorie d’évaluation comme suit : Niveau de Risque = (Score/Points Possibles) x Impact

On peut distribuer à l’équipe projet ou aux stakeholders un formulaire d’évaluation des risques par catégorie (voir exemple ci-dessous). Cette approche par catégorie peut apporter une meilleure réponse au risque, plus structurée.

Évaluation par catégorie des risq de l’impact et du score Id1. Engagement 1 2 3 et responsabilité du client 1 Est-ce que le client a compris et Oui En gros Un pe accepte les conditions du

2

3

contrat ? Est-ce que le client a compris et accepte la charte du projet ? Est-ce que le client a compris et accepte l'impact d'un retard dans le planning s’il ne met pas à disposition les ressources nécessaires durant la durée du projet?

Oui En gros

Un pe

Oui En gros

Un pe

Questions Répondues/Score To Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa 1 2 3 2. Définition de l’offre 1 L’offre répond clairement aux spécifications Oui En gros Un pe et exigences du client 2 Les exigences du client sont comprises et Oui En gros Un pe documentées clairement 3 Les objectifs du projet sont bien définis et Oui En gros Un pe

clairs (SMART) 4 Le scope du projet est Oui En gros Un pe suffisamment détaillé Questions Répondues/Score To Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa 1 2 3 3. Planning 1 Le planning est réaliste et permet de réaliser toutes Oui En gros Un pe les activités dans les délais impartis 2 Est-ce que le

délai est critique pour le client ? 3

Non

Oui

Le chemin critique est-il Oui En gros Un pe identifié ? 4 Tous les livrables définis dans le contrat Oui Presque Un pe sont-ils identifiés ? Questions Répondues/Score To Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa 2 3 4. Expérience et 1 capacité 1 A-t-on

l’expérience et Oui Presque Limit la maturité pour mener un tel projet ? 2 Dispose-t-on de suffisamment de ressources Oui Presque Limit compétentes, au savoir-faire adéquat ? Questions Répondues/Score To Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa 1 2 3 5. Durée 1 Est-on certain de disposer des ressources

pendant la durée du projet ?

Oui

Questions Répondues/Score To Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa 1 2 3 6. Cadre légal et contractuel 1 Dans le cas où les termes et les conditions ne sont pas Oui Non standards, N/A l’offre a-t-elle été revue par les juristes ?

Questions Répondues/Score To

Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa

7. Technologie 1

Le vendeur d’application s’est-il engagé à s’assurer de la compatibilité et du support de son logiciel pour une période égale à notre engagement envers le client ?

1

Oui N/A

2

3

Questions Répondues/Score To

Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa 1 2 3 8. Complexité de la solution 1

Les ressources clés sont-elles disponibles Oui Presque certain pour tacler les besoins du client? Questions Répondues/Score To Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa

9. Finance 1

2

Tous les coûts ont-ils été identifiés et sont-ils inclus dans les estimations?

1

Oui

2

3

Non

Les termes de livraisons sontils clairement Oui Non définis et compris par tous ? Questions Répondues/Score To Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa

10. Intégrateurs

1

2

3

et soustraitants 1

2

Tous les termes du contrat avec le client sont-ils inclus également dans celui des intégrateurs (i.e : garantie, facturation, pénalités, performance, etc.) ? Dans le cas où le sous-traitant développe un

NA

Oui

logiciel, a-t-on pris toutes les dispositions s’il devient insolvable ?

Oui

Questions Répondues/Score To Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa 1 2 3 11. Handover vers le Support 1

Tous les accords pour le passage en mode opération sont-ils

Oui

2

formellement documentés avec le client ? Le processus de traitement des erreurs issues du projet en mode opération est-il en place ?

Oui

Questions Répondues/Score To Impact (5=Critique ; 1=Mineu Niveau de Risque = (Score/Points Possibles Impa Exemple 88 : Évaluation par catégorie des risques en fonction de l’impact et du score

Le tableau ci-dessous, dans lequel on a associé une valeur de poids à chaque catégorie, résume le résultat de l’évaluation des risques par catégories. Ce poids correspond au degré d’importance de chaque catégorie par rapport aux autres catégories. RÉSUMÉ DES RISQUES 1. Engagements et responsabilité du client 2. Définition de l'offre 3. Planning 4. Expérience et capacité 5. Durée 6. Cadre légal et contractuel 7. Technologie

Impact par catégorie 5 4 3 5 3 3 3

8. Complexité 9. Finance 10. Intégrateurs et soustraitants 11. Hand-over vers le Support

3 3 3 3

Le tableau ci-dessus ou le graphe cidessous montre le niveau de risque par catégorie. Grâce à ces résultats, il ne nous reste plus qu’à concentrer nos efforts sur les niveaux de risques les plus grands, à traiter en priorité.

Exemple 89: Spectre des niveaux de risques par catégorie

Mettre en œuvre l’ana risques

Ce processus consiste à l’analyse numérique des effets des risques précédemment identifiés et priorisés sur l’ensemble du projet. Contrairement à l’analyse qualitative des risques qui implique généralement une évaluation instinctive de différentes catégories de risque, l’analyse quantitative nécessite des données statistiques quantifiables numériquement. Pour ce faire, soit il faut quantifier l’évaluation qualitative que l’on vient d’effectuer, soit il faut des données empiriques dont les sources peuvent être les suivantes : Des données issues d’une étude ou de consultation ; Des données historiques issues des

expériences et leçons du passé sur d’autres projets ; Des sessions de brainstorming ; Simulation ou test ; Experts sur le sujet. Méthode des Trois Points (Minimum, Probable, Maximum) L’analyse quantitative des risques peut s’effectuer de différentes manières. L’une d’entre elles repose sur les estimations ponctuelles de nature déterministe, par exemple en affectant des valeurs à chaque activité du WBS et en évaluer l’issue. Dans l’exemple ci-dessous d’estimation des coûts, on examine les points

suivants : L’estimation de coût maximum représente le pire des cas, le risque est de devoir investir plus pour le projet ; L’estimation de coût probable représente le cas le plus probable ; L’estimation de coût minimum représente le cas le plus favorable. COÛTS Phase Activité

Maximum Probable (au pire)

Équipements 150 000 € 115 000 € Phase Collecte des 40 000 € 30 000 € 1 exigences Design : Phase conception 60 000 € 50 000 €

2

de la solution Préparation Phase de 3 l'intégration Phase 4 Déploiement Phase Hand-over 5 support

20 000 €

18 000 €

25 000 €

20 000 €

16 000 €

12 000 €

311 000 € 245 000 € Exemple 90 : Analyse quantitative des risques – Méthode des Trois Points

Dans cet exemple, il faut toujours prendre en compte les causes spécifiques qui se cachent derrière les valeurs min. et max., et, surtout, il ne

faut jamais hésiter à demander sur quelle base ces estimations ont été faites. La simulation Monte-Carlo Il existe sur le marché nombre d’outils et de techniques pour effectuer les analyses quantitatives ; @Risk ou Crystal Ball sont, entre autres, des exemples de logiciel d’analyse quantitative des risques. Ces outils reposent souvent sur des analyses de risque stochastiques de la simulation Monte-Carlo. Cette approche nécessite une plage de distributions de probabilités pour chaque activité, ce qui représente le profil des risques. Les distributions de probabilités les plus fréquentes sont : A : Distribution B : Distribution

Uniforme

Toutes les valeurs ont une chance égale de se réaliser

Triangulaire

Le sommet du triangle représente la valeur la plus probable

Ensuite, une fois que le choix de la distribution est fait, il faut lancer la simulation autour de 500 à 1000 itérations et en évaluer le résultat. Enfin, ces résultats peuvent être présentés par des graphes qui sont beaucoup plus simples à lire, surtout

quand on doit présenter les risques dans un rapport. Voici ci-dessous quelques diagrammes fréquemment utilisés. Diagramme 1 : Diagramme de distribution de fréquence d’occurrence Une distribution de probabilité dans le diagramme ci-dessous décrit la fréquence d'occurrence de valeurs d’estimations de coût total du projet. On voit que sur 150 itérations, le coût total le plus probable pour réaliser le projet est de 250k€. Le diagramme montre combien de fois un coût estimé se produit.

Figure 41: Analyse quantitative des risques Diagramme de fréquence d’occurrence

Diagramme 2 : Courbe de probabilité Cette courbe montre la probabilité de finir le projet en-dessous ou au-

dessus du budget. Avec un tel résultat, on peut affirmer qu’il y a 85% de chance que le coût total du projet soit de 250k€.

Figure 42: Analyse quantitative des risques -

Courbe de probabilité

Planifier les réponses Il s’agit maintenant de parer aux risques susceptibles de heurter le projet en mettant en place des plans d’actions préventives ou correctives afin de les éviter ou encore un plan de contingence quand le risque heurte le projet. La réponse au risque dépend des organisations car chacune a ses propres critères de risques et seuil au-delà duquel il n’est plus question de prendre des risques. Par exemple, une personne a le choix entre trois solutions pour sa

pension de retraite : le premier choix est plutôt conservateur et implique que son employé épargne 100% de la valeur de sa pension ; le deuxième choix implique que l’employeur épargne 50% de sa pension et place les autres 50% en bourse sachant que ce placement peut fluctuer en fonction du marché. Si le marché se porte mal au moment où le salarié part à la retraite, il peut perdre la quasi-totalité des 50% joués en bourse mais il pourra toujours récupérer les autres 50% cotisés par son employeur. En revanche, si le marché se porte bien, le salarié aura gagné déjà les 50% épargnés et il aura fait fructifier les autres 50% placés en bourse. Dans ce

cas-là, le salarié gagnera davantage que dans le premier choix qui lui est offert. Enfin, le troisième choix implique que le salarié autorise son employeur à placer en bourse 100% de sa pension : on est dans la configuration « ça passe ou ça casse » car sa retraite dépend du marché. Le salarié peut gagner très gros comme il peut aussi perdre très gros et doit être prêt mentalement à accepter ce résultat négatif en plus de la perte financière. Chacun a son seuil de risque et ses critères de prises de risques et la réponse à ces risques est différente d’une personne à l’autre comme d’une organisation à l’autre. Seuil et critère de risques

On tombe souvent sur les critères de prise de risque suivants : Critère Maxi-max : Maximum de mise avec maximum de risque. On est dans un cas ou ceux qui prennent des risques sont très optimistes car ils maximisent le résultat en passant par un « quitte ou double ». C’est le cas du salarié qui autorise son employeur à placer 100% de la cotisation pour sa pension en bourse. Ils peuvent tout gagner comme tout perdre. N’a-ton pas dit un jour que ceux qui risquent de tomber très bas peuvent monter très haut aussi ? Critère Maxi-min : Maximum de

mise avec un minimum de risque. On est dans un cas où ceux qui prennent les risques sont concernés par les pertes potentielles. Ils vont alors établir un seuil maximum au-delà duquel ils ne prendront pas de risque pour minimiser la perte. Ils minimisent en quelque sorte le maximum de pertes. On est dans le cas où le salarié autorise son employeur à miser seulement 50% de sa pension en bourse et de cotiser normalement les 50% restants ; Critère Mini-max : Minimum de mise avec un maximum de regret. On est dans le cas de figures des grands

losers, des perdants qui essaient de tirer le maximum de ce qui aurait pu être gagné en prenant un minimum de risque. Ne dit-on pas que ceux qui risquent peu gagnent peu aussi ? La décision prise minimise le maximum de regret. On est dans le cas où le salarié ne laisse pas son employeur placer en bourse la cotisation pour sa retraite. Le salarié prend un minimum de risque et sera garanti de recevoir le maximum de ce qui est placé. Réponses aux risques qui menacent le projet Afin de parer aux risques susceptibles d’avoir un impact négatif sur le projet, le PMBoK® recommande les techniques

suivantes : Transferts des risques : il s’agit de déplacer l’impact d’une menace vers un tiers, ainsi que la responsabilité de la réponse à ce risque. Ce mécanisme de transfert ne modifie pas la probabilité de survenance du risque ni de ses conséquences. Le risque n’est donc pas éliminé pour autant et existe toujours, seulement, l’organisation cède un risque, par définition aléatoire, à une tierce organisation. C’est un peu comme transférer la patate chaude vers une tierce personne, la patate reste chaude mais elle n’est plus dans vos mains. Par exemple, on peut sous-contracter la

partie à risque. On peut tout aussi bien prendre une assurance, qui fournit une prestation lors de la survenance du risque. On peut penser, par exemple, à s’assurer contre les risques suivants : Dommages matériels directs : il faut se protéger contre les vols ou dégâts causés aux matériels et équipements du projet. Par exemple, il arrive que des équipements que l’on vient de livrer disparaissent. Dans ce cas, soit il faut transférer la responsabilité vers le client, soit on prend une assurance contre les vols sinon c’est au projet de prendre en charge le coût de

remplacement des équipements disparus ; Pertes indirectes conséquentes : il arrive que le projet soit victime indirectement d’interruption de business du client pour cause de crise financière mondiale empêchant le client de continuer le projet dans les délais prévus ; Protection juridique professionnelle : elle permet de se décharger des problèmes juridiques et administratifs qui peuvent perturber le déroulement

du projet. Elle permet de faciliter le règlement des litiges sur les erreurs de design ou d’exécution ou encore en cas d’échec de livrer le projet avec la performance exigée. Etc. Atténuation des risques : il s’agit ici de réduire la probabilité d’occurrence ou d’impact d’un risque en dessous d’un seuil acceptable. Par exemple, afin d’atténuer les risques dans un déploiement de Téléphonie sur IP (ToIP), insister sur la préparation et commencer un site pilote réduit considérablement les

risques de déploiement. Un autre exemple est un grimpeur qui atténuerait le risque de mettre sa vie en danger par une corde. Aller dans une salle d’escalade pendant plusieurs mois avant de s’attaquer à une vraie falaise peut atténuer les risques de chute également.

Mitigation des risques q imposés On trouvera toujours, au sein d’une o mesure d’imposer la date de fin d’un certains managers de projet, facilemen tendance à obéir aveuglément et à prend planning, souvent au détriment de la qu Ces managers de projet vont tomber

établir le planning en partant de la date les activités en remontant vers la date d A ces managers de projet, je conseille l’

Étape 1 : commencer à faire le p processus tels qu’ils sont expliqués d managements du délai. À ce stade, il créer son planning en respectant les poi 1. Ne tenir en compte que les compte les activités à faire e accélérer les travaux ; 2. Ne tenir compte que des ress projet en temps normal avant 3. Ne pas mettre d’accélération ( ou d’autres considérations spé

Étape 2 : comparer la date de fin du pla de fin imposée afin d’évaluer le nombre

Figure 43: Risque - Plann

Étape 3 : Maintenant, on peut comm peut prendre pour réduire la durée du chaque tâche en analysant toute inform l’on peut compresser, le changement d comme suit :

Approche Compression Tâche B : Ajouter deux Architectes Réseaux Faire Tâches D et C en parallèle Tâche A : Assembler les équipements avant de les expédier

Délai Coût Risque Inc Co 10 jours

10 jours 5 jours

Étape 4 : classifier et prioriser la liste compression de délai requis en augm risques. Il faut travailler avec son éq confiance pour livrer le projet à la date

issue de l’étape 3.

Étape 5 : le Manager de Projet doit fa qui prennent les décisions et s’assurer avec les coûts et risques supplémentaire Exemple 91 : Mitigation des risques quand la date de fin d’un projet est imposée

Évitement des risques : il s’agit de manipuler le planning en introduisant des modifications au plan de management de projet, modifications destinées à éliminer le risque ou à protéger de son impact les objectifs du projet. Il ne faut pas éliminer la possibilité d’arrêter le projet si le risque persiste car, parfois, le jeu n’en vaut pas la chandelle. On a déjà tellement

rencontré d’organisations qui ont accepté de signer le lancement de projets à perte juste pour le prestige d’avoir gagné un contrat, alors que le risque de ne pas avoir un ROI positif était toujours présent. La sagesse serait, dans ce cas, d’arrêter le projet ; Acceptation du risque : il s’agit d’accepter de courir le risque et d’en subir les conséquences négatives si le risque se matérialise. L’équipe projet accepte donc de ne pas modifier le plan de management du projet pour répondre au risque, soit parce qu’on ne trouve pas d’autres

stratégies adéquates soit parce que le risque est inévitable. Dans ce cas, il faut donc modifier le planning en incluant un buffer pour exécuter le plan de contingence, et en incluant une réserve dans le budget du projet pour prendre en charge le coût de l’exécution du plan de contingence. Accepter la prise de risque peut avoir des côtés positifs car cela peut révéler une capacité à entreprendre une action avec une certaine marge d’incertitude.

Surveiller et maîtriser Il y a des managers de projet qui sont en mode réaction à chaque fois

qu’il arrive quelque chose d’imprévu à leur projet. Certains ne voient pas les choses arriver et se posent sincèrement la question de savoir ce qui a bien pu se produire sur leur projet alors qu’ils n’ont absolument pas conscience de leur rôle dans le désastre qui vient d’avoir lieu. Certains PM veulent être bien vus et afficher un projet qui semble parfait, pour ce faire, ils n’évoquent donc pas les risques ou alors les renient. Enfin, il y a les chanceux dont le projet s’est bien déroulé à quelques déviations près. Mais la chance n’est-elle pas due au fait que les mesures de prévention et les actions de corrections effectuées par le manager ont tout simplement rencontré

un succès pour éliminer ou atténuer l’impact des risques ? Ces managers de projet ont bien anticipé et traité en amont tous les événements qui auraient pu avoir une conséquence néfaste sur leur projet. Ce type de Manager de Projet sait faire vivre son fichier de Risques Log et de Problèmes Log afin de mieux contrôler et surveiller le projet. Ce Manager de Projet a aussi réussi à identifier les risques, a su les évaluer et a su y apporter les réponses appropriées. Il n’est point besoin de rappeler qu’identifier les risques n’est pas un exercice auquel on se prête seulement en début de projet, au contraire, il doit faire partie intégrante

du quotidien du Manager de Projet. En agissant de la sorte, le Manager de Projet surveille et maîtrise continuellement les risques. Certains managers de projet se contentent seulement de discuter des actions en cours et de celles à venir. Cependant, à chaque réunion sur l’état et les progrès du projet avec l’équipe projet ou avec les stakeholders, il faut toujours aborder les risques et les problèmes en cours et prendre les décisions adéquates, que cela soit des actions de prévention ou de correction pour contrôler et surveiller les risques constamment tout au long du projet. Les amateurs, ou ceux qui n’ont

jamais managé de projet, ne se préparent pas aux désastres, ne font pas l’effort de penser aux scénarios du pire et présument que tout va toujours bien se passer. Néanmoins ce ne sera jamais le cas, il y aura toujours une déviation. Le professionnel du management du projet ne laisse rien au hasard. Il décèle, contrôle et maîtrise les risques qui peuvent survenir sur un projet. Ainsi, quand le scénario du pire vient à se réaliser, il est prêt avec son plan d’action de mitigation, sans improviser, ni compter sur « le petit bonheur la chance ».

Management des Approvisionnements du projet

Dès les premières phases d'un projet, à l’écriture de la Charte de Projet ou encore pendant la préparation du Business Case, toute organisation est

amenée à se poser la question du « make or buy », à savoir, si elle a la capacité de réaliser le projet elle-même (inhouse) ou, pour d’autres raisons stratégiques du business, si elle doit externaliser la réalisation du projet. Les options suivantes s’offrent alors à l’organisation : 1. Réalisation du projet totalement en interne : le projet est réalisé avec les moyens dont dispose l’organisation en interne, à savoir les matériels, les logiciels et les ressources humaines ; 2. Réalisation du projet avec des ressources mixtes composées d’internes et d’externes : le projet

est réalisé en interne et il faut acquérir en externe soit du matériels, des logiciels, des études, des résultats, ou encore des services dans le cas où l’organisation n’a pas la compétence sur certains aspects du projet, ou encore si ses ressources ne sont pas disponibles pour ces derniers. Elle peut alors faire appel à des prestataires pour réaliser une partie du projet pendant un laps de temps donné tout en conservant la responsabilité du projet. Les lois sociales en France ne permettent pas d’embaucher et de débaucher le personnel facilement. En faisant appel à un prestataire,

l’organisation s'offre les services de spécialistes pour une durée déterminée. Elle peut également profiter des transferts de compétences qui ont souvent lieu entre les éléments externes et les équipes internes. En effet, l’organisation doit faire monter en compétences ses ressources afin de réaliser le projet. Pour ce faire, elle est obligée d'investir lourdement en formations coûteuses et pouvant monopoliser le temps de travail de ses collaborateurs. Dès lors, travailler avec des spécialistes externes, experts dans leur domaine, permet à l’organisation d’être à la

pointe à tous les niveaux. Travailler avec une société externe permet aussi de bénéficier des dernières technologies disponibles dans un domaine donné au travers de l’externalisation. La performance et la compétitivité s'en trouvent ainsi optimisées ; 3. Réalisation du projet avec des ressources totalement externes : l’organisation achète le service, le produit ou le résultat que le projet devait livrer à une compagnie externe. Ainsi, l’organisation peut, par exemple, se focaliser sur son cœur de métier et transférer la responsabilité de la réalisation du

projet à la compagnie sous-traitante, qui doit s’engager sur des résultats dans un délai et un budget définis dans le contrat. Il est parfois plus facile d’obtenir ces garanties de résultat avec une équipe externe qu’interne, car il existe un moyen de pression à la compagnie externe qui est celle des pénalités en cas de retard dans la livraison du projet, ou encore celle des dédommagements en cas de non respect de clause ; Le domaine des connaissances du management des approvisionnements du projet traite la gestion des biens et services fournis par d’autres organisations fournisseurs qui livrent

une ou plusieurs parties du projet. Il comprend les processus et les activités qui se rapportent à l’achat de services, de produits ou des résultats nécessaires au projet.

Figure 44: Management des approvisionnements

du projet (PMBoK®)

Planifier les approvisi

Acquérir tout ou une partie d’un produit, d’un résultat ou d’un service pour réaliser le projet nécessite préparation et planification, sans quoi le Manager de Projet avance en improvisant, ce qui diminue la chance de succès de son projet. Cette planification doit être alignée avec la stratégie d’approvisionnement de l’organisation. Le plan des approvisionnements doit comprendre au minimum les éléments suivants : 1. Le contexte du projet : il faut définir le contexte qui justifie la nécessité de faire appel à une compagnie de sous-traitance sur le

projet. Pour ce faire, il faut définir les suivants : Objectif du business : on doit s’interroger sur les raisons motivant le business à faire appel à un fournisseur. Il faut élaborer un cahier des charges précis qui comprend la définition des objectifs que la compagnie soustraitante doit atteindre. Ce document doit comprendre également les exigences fonctionnelles du business ainsi que les exigences techniques ; Le scope du projet : il faut définir le périmètre d’intervention de chacun - le client et, surtout, le

fournisseur - en incluant les frontières du scope du projet telles que les contraintes pour réaliser le projet, les hypothèses émises pour finaliser le scope et, enfin, les dépendances par rapport à d’autres projets ; La matrice RACI sur le projet : il faut définir les rôles et responsabilités de l’équipe interne et externe sur le projet. Il est conseillé de disposer d’un responsable de la fonction externalisée en interne - rôle qui incombe souvent au Manager de Projet - qui doit être chargé du lien entre les deux structures.

2. Les exigences commerciales : une fois que le contexte du projet par rapport à l’intervention du fournisseur est bien défini, il faut passer à la définition des exigences commerciales, à savoir les besoins, par phase du projet, pour lesquels il faut établir une relation stratégique et commerciale avec un fournisseur ou un partenaire de business afin de répondre au contexte du projet nécessitant l’utilisation d’une compagnie ou d’une personne soustraitante. Par exemple, les besoins suivants : Besoins de fournisseur en

équipements téléphoniques en phase d’initiation du projet ; Besoins de service d’intégrateurs téléphoniques tout au long du cycle de vie du projet ; Etc. 3. L’approche commerciale : il faut ensuite définir la façon dont on va répondre au contexte du projet et ses exigences commerciales. Dans certaines organisations, la direction des achats fixe l’approche commerciale : par exemple, quand le montant de l’achat est inférieur à une certaine somme (50k€ par ex.), le Manager de Projet garde le champ

libre. Cependant, si le montant est supérieur au seuil fixé par l’organisation, il devra passer devant un comité (Sourcing Board) ou par le département d’achat pour faire valider son approche. En général, et suivant le marché (public ou privé) et les régulations locales, les organisations disposent des possibilités suivantes : Un fournisseur existant : l’organisation peut faire appel à un fournisseur avec qui elle traite déjà sur un autre projet. Il suffit tout simplement d’ajuster le contrat existant en incluant le produit, service ou résultat que le

fournisseur doit livrer. Appel d’offres : l’organisation peut décider de mettre plusieurs entreprises fournisseurs en concurrence pour fournir le service ou produit qui répond au besoin du projet. Des exemples de sources de diffusion officielles d’appel d’offres sont le BOAMP (Bulletin officiel des annonces de marchés publics) et le JOUE (Journal officiel de l'Union européenne). Appel d’offres international La SOTELMA (Société de Télécommunication du Mali)

a décidé en juillet 2008 de procéder à la privatisation de 51% de son capital en recherchant, pour ce faire, un partenaire stratégique sur la base d’un appel d’offres international. L’envoi du dossier d’appel d’offres s’est déroulé du mois d’Août à Octobre 2008 et la réception de 4 offres comprenant un dossier administratif et technique, sans oublier une offre financière, en janvier 2009. Cette dernière opération a porté Maroc Télécom à la tête des prétendants car elle avait proposé la plus forte somme (165 milliards de francs CFA soit 252 millions

d’euros). Exemple 92 : Approvisionnement - Appel d'offres international

Appel à propositions : sans passer par un appel d’offres officiel, l’organisation peut faire appel aux entreprises fournisseurs, avec qui elle a l’habitude de faire affaires, pour lui soumettre des propositions financières et techniques pour la réalisation d’une prestation sur le projet. Appel à propositions L’Union européenne dépense son budget de 2 manières : les appels

d’offres pour le marché public et les appels à propositions pour les subventions entre autres pour participer aux Programmes Cadre de Recherche et de Développement Technologique (PCRDT). Par exemple, dans le domaine du 7e PCRDT concernant la publication des appels à propositions de la thématique Technologie de l’Information et de la Communication et du programme de travail ICT 2010, avis a été donné du lancement d’appels à propositions, notamment le premier appel à propositions pour le Partenariat Public-

Privé sur l'Internet du Futur, au titre des programmes de travail « Coopération », « Idées », « Personnes » et « Capacités » pour des actions de recherche, de développement technologique et de démonstration (20072013). Les délais à respecter et les budgets impartis, comme les critères d’évaluation, étaient indiqués dans le texte publié au Journal Officiel N° C196 du 20 juillet 2010. Exemple 93 : Approvisionnement - Appel à propositions

Fournisseur unique : il arrive que le processus ouvert et

concurrentiel d'appel d'offres puisse ne pas être envisageable, souvent à cause des raisons suivantes : l’organisation veut assurer la compatibilité avec ses produits existants ; pour des raisons d'ordre technique, il y a absence de concurrence, les produits ou services ne peuvent être fournis que par un fournisseur donné et il n'existe aucune solution de rechange ni produits ou services de remplacement ; l’achat d'un prototype, d'un produit ou d’un nouveau

service doit être mis au point par l’unique fournisseur. L’organisation se voit donc contrainte d’avoir recours à des contrats avec un fournisseur unique. S'il y a bien une situation que les acheteurs détestent, c'est celle de négocier en position de faiblesse avec un seul fournisseur car ce dernier, se sachant unique, peut abuser de sa position de force pour exagérer son offre.

Procéder aux approvis

Je le répète encore, avant de passer à toute exécution, comme à cette étape, un plan d’approvisionnement doit être préalablement bien défini comme mentionné dans le processus précédent.

Figure 45 : Courbe de peine et douleur

La courbe des peines (fig. ci-dessus) montre que planifier en amont peut être

douloureux, car c’est un exercice intense requérant énormément d’efforts en début de projet : les informations arrivent de partout sans aucune structure et il revient au Manager de Projet de leur imposer un cadre afin de les gérer, les planifier, étudier les risques, monter un budget, etc., mais on récoltera toujours le fruit de ses efforts de préparation plus tard dans le projet. Par contre, sans planning préalable, à savoir sans préparation minutieuse, les douleurs et les peines ne feront qu’accroître graduellement tout au long du projet jusqu’à devenir intenables parfois. Le manque de planning est un facteur qui réduit la chance de réussite du projet.

Procéder aux approvisionnements est un processus qui consiste à mettre en œuvre ce qu’on a défini dans le plan d’approvisionnement en procédant par étape comme indiqué dans la figure cidessous.

Exemple 94 : Procéder aux approvisionnements

Dans une méthodologie de projet organisée par portes d’étape (stage gates), si le cahier des charges, le plan projet et les exigences commerciales, qui justifient l’appel à un fournisseur, ne sont pas bien définis, rédigés ni encore validés, on ne peut mettre en place l’approche commerciale consistant, à moins que l’organisation ne fasse appel à un fournisseur existant ou à un fournisseur unique, en la mise en place d’une procédure d’appel d’offres ou d’appel à propositions. Cette procédure peut comprendre plusieurs étapes permettant la diffusion vers les soumissionnaires des informations

nécessaires à la réalisation d’une proposition complète et précise pour ensuite apprécier leurs réponses sur la base de critère définis au préalable. En général, le projet à sous-traiter est lotisé (minimum 1 lot) afin de permettre à chaque soumissionnaire de répondre à tout ou partie de l’appel d’offres/propositions en tenant compte de ses véritables compétences. RFP, RFT, RFQ, RFI, etc. Dans la procédure de diffusion de l’appel et d’analyses des réponses à l’appel, l’organisation peut demander un certain nombre de dossiers à plusieurs fournisseurs potentiels préalablement identifiés, souvent les suivants :

RFP (Request For a Proposal) : invitation à soumissionner dans laquelle l’organisation demande aux soumissionnaires un dossier d’offres qui comprend une proposition technique et une proposition financière. La RFP est assimilée à l’appel d’offres des marchés privés. RFT (Request For Tender) : invitation à soumissionner dans laquelle l’organisation demande aux soumissionnaires un dossier d’offres qui comprend une proposition technique et une proposition financière. La RFT est assimilée à l’appel d’offres des marchés publics. RFQ (Request For a Quotation) :

terme commercial B to B désignant une demande de devis. L’organisation demande aux soumissionnaires les estimations des coûts qui seront engendrés pour la réalisation d'un nouveau produit ou d'une prestation de service. La RFQ peut être assimilée à un appel d’offres. RFI (Request For Information) : demandes d’information qui ont pour objectif d’évaluer la faisabilité de projets sur un plan technique et financier. Elles doivent permettre de réunir les éléments nécessaires à la détermination de solutions techniques répondant au besoin et d’explorer les différents schémas financiers

possibles et les cadres contractuels permettant de les supporter. Ces demandes d’information ne constituent en aucun cas un engagement précontractuel de l’organisation qui en fait la demande aux soumissionnaires. C’est juste une demande invitant le fournisseur à donner plus d’informations sur l’un de ses produits ou services. Une RFI est moins formelle et plus facile à traiter qu’une RFP ou une RFQ. Évaluation d’appel d’offres ou d’appel à propositions Les réponses fournies par les soumissionnaires sont évaluées par une commission d’évaluateurs internes à

l’organisation ou par des experts externes indépendants, auquel cas l’évaluateur s’engage alors à n’avoir aucune participation personnelle aux projets concernés par les candidatures à expertiser et certifie que l’organisme auquel il appartient n’a pas déposé de candidature et/ou n’est pas partenaire pour un projet et n’a pas eu un rôle de conseil au montage d’un projet. Enfin, il déclare n’avoir aucun intérêt personnel qui pourrait influencer son impartialité. Ce serait contraire à toute éthique. Il s’agit de s’assurer que les évaluateurs présentent toutes les garanties nécessaires de neutralité et d’indépendance vis-à-vis de

l’organisation et des projets pour lesquels cette dernière a lancé l’appel d’offres. Chaque appel d’offres ou appel à propositions comprend sa propre grille d’évaluation objective, les critères d’évaluation objective étant préalablement définis dans le plan d’approvisionnement ainsi que dans les dossiers de RFP, RFQ, etc. Dans la plupart des cas, on évalue les suivants : Évaluation générale La pérennité des soumissionnaires et les éléments contractuels sont vérifiés ; La fiabilité des compétences, des équipes et la rigueur des

méthodologies proposées ; La qualité fonctionnelle et organisationnelle de la réponse ; La proximité du prestataire ; Etc. ; Évaluation technique La compréhension du besoin exprimé ; La qualité technique et innovation scientifique ou technologique des réponses ; Budgétaire La compétitivité et clarté du budget proposé ; L’analyse des documents

économiques ; Risques Le choix d’une liste prioritaire s’enchaîne ensuite pour l’organisation et s’engagent alors une discussion et des négociations auprès de ces soumissionnaires repris dans la « shortlist ».

Choix du pays organ choix du pays hôte a ét Pays Villes Hôtes Stades (exigence FIFA : 12) Proposé A rénover A construire

Budget rénovation/construction (Billion USD) Lieux spécifiques d’entrainement Requis Proposés Hôtels spécifiques pour les équipes Requis Proposés Camps de base d’entrainements Exigence FIFA=64 ; proposé Hôtels camps de base des équipes Exigence FIFA=64 ; proposé

Hébergement (conforme à FIFA) Exigence FIFA=60 OOO ; proposé Budget de Dépenses (Millions USD) Projection vente de ticket Risques Stade en construction Opération dans les stades Infrastructure pour les équipes Evénement concurrent Aéroport et connexion international Transport Terrestre Transport dans les villes hôtes Hébergements

Infrastructure pour les TV

On sait tous que la décision de la de la coupe du monde de Football au Quatar. Exemple 95: Evaluation d'appel à propositions pour organiser une Coupe du Monde

Le contrat entre le client et le fournisseur Une fois que le choix du fournisseur est fait, il faut sceller les accords trouvés pendant la phase de négociation par un contrat. En effet, tout appel à un fournisseur se fait sous forme d’un contrat commercial entre les deux parties. Lors de la négociation de celui-

ci, l'objectif de l’organisation est de mettre sur le fournisseur le maximum de risques tout en lui donnant un intérêt à se montrer efficace et rentable. Quant au fournisseur, il voudra diminuer le risque qu'il encourt tout en augmentant son profit potentiel. On retrouve souvent les 3 types de contrats suivants : 1. Contrat à coûts remboursables : le client devra rembourser le fournisseur pour toutes les charges relatives aux prestations. Les contrats à coûts remboursables comportent souvent des clauses prévoyant l'intéressement du fournisseur en fonction du respect ou

du dépassement de certains objectifs du projet, par exemple des échéances cibles ou le coût total ; 2. Contrat à prix fixe : le fournisseur s’engage à effectuer les travaux à l’avance, pour un montant fixé dans le contrat et dans un délai déterminé, avec éventuellement une clause de révision du prix pour le protéger de l’inflation ; 3. Contrat aux temps et matériels : c’est une forme hybride du contrat à coûts remboursables et à prix fixe. Dans ce cas, le décompte de la prestation se fait au temps réellement passé et aux matériels réellement fournis.

Contrat à coûts remboursables : CPF, CPAF, CPIF, etc. Dans ce type de contrat, le client rembourse au fournisseur les coûts réels encourus majorés de différents types d’honoraires qui constituent généralement le bénéfice du fournisseur. On rencontre souvent les contrats à coûts remboursables suivants : Contrat en régie avec prime au mérite [Cost Plus Award Fee (CPAF)] : le client rembourse au fournisseur les coûts réels encourus majorés d’une prime au mérite ; Contrat en régie avec honoraires fixes [Cost plus Fixed Fee (CPF)] : le fournisseur est remboursé pour les

coûts réels encourus admissibles à la réalisation du contrat majoré d’honoraire fixe. Cet honoraire fixe, étant le profit du fournisseur, est versé au montant convenu dans le contrat. Généralement, ce montant est un pourcentage de la valeur estimée du contrat. À moins d'un changement dans le contrat, ce montant reste constant tout au long de son exécution. Dans l’exemple cidessous, le client paiera toujours au fournisseur les coûts réels encourus par le fournisseur auxquels il faut toujours ajouter 50k€ d’honoraire ;

Exemple 96 : Contrat à coûts remboursables avec honoraire fixe (CPF)

Contrat en régie avec intéressement [Cost plus Incentive fee (CPIF)]: le fournisseur est remboursé pour les coûts réels encourus admissibles à l'exécution du

mandat. Par ailleurs, il recevra un honoraire dont le montant est fixé dans le contrat en plus de la possibilité de bénéficier d’un bonus. Ce bonus sera payé si le coût final est inférieur à la valeur de l'estimation. Le montant épargné au contrat sera partagé entre le fournisseur et le client dans une proportion entendue (ratio client/fournisseur). Dans l’exemple ci-dessous, le client et le fournisseur s’étaient mis d’accord pour un ratio client de 50% et de fournisseur de 50%. Ils s’étaient également entendus sur la cible qui stipule que pour 100k € de coût, le fournisseur se verrait

attribué un honoraire de 20k€. Mais si les coûts du fournisseur s’avéraient plus ou moins élevés par rapport au coût cible (100k€), il faudrait alors ajuster l’honoraire avec un montant d’ajustement qui se calcule comme suit : (Coût cible – Coût Réel) x Ratio Par exemple, si les coûts du fournisseur sont de 120k€, le montant d’ajustement de l’honoraire serait (100k€ - 120k€) x 50% = -10k€, ainsi, l’honoraire pour 120k€ de coûts est de 10k€, et le prix à payer par le client au fournisseur serait de 130k€. De ce fait, autant le

fournisseur que le client ont un avantage à voir le projet se réaliser dans les coûts les plus faibles possibles ;

Exemple 97: Contrat à coûts remboursables

avec intéressement

Contrat en régie avec pourcentage des coûts [Cost-pluspercentage of costs contract] : il assure au fournisseur le remboursement des coûts admissibles. De plus, celui-ci reçoit un pourcentage entendu dans le contrat de ce coût admissible en profit. Du point de vue du client, ce type de contrat est pratiquement inacceptable puisqu'il n'y a aucune motivation pour le fournisseur à réduire les coûts. En fait, le fournisseur aura plutôt tendance à

vouloir augmenter les coûts puisque, de ce fait, il augmentera ses profits. Mais si le client signe ce type de contrat, il lui faudra faire preuve de vigilance concernant le contrôle des heures de travail et le coût d'acquisition des matériaux, pour s'assurer que le fournisseur n'augmentera pas ces coûts uniquement dans le dessein d'augmenter son profit. Contrat à prix fixe : FFP, FPIF, PTA Pour ce type de contrat à prix fixe, où le fournisseur accepte de fournir le service dans le délai imparti et pour un montant fixe, on rencontre souvent les variations suivantes :

Contrat à prix fixe ou forfaitaire [Lump Sum - Firm Fixed Price (FFP)] : dans ce type de contrat, le fournisseur s'engage à exécuter le mandat à un prix spécifique fixé dans le contrat. Contrat à prix fixe avec intéressement [Fixed Price Incentive Fee (FPIF)]: ce type de contrat comporte un coût ciblé, un profit ciblé, un prix ciblé, un prix plafond et une formule de partage des économies de coût. Si le coût réel du projet est en deçà du coût ciblé, alors le montant épargné au contrat sera partagé entre le fournisseur et le client dans une proportion entendue

(ratio client/fournisseur). Dans l’exemple ci-dessous, ce ratio est de 75% pour le client et de 25% pour le fournisseur, et si les coûts du fournisseur sont plus élevés ou moins élevés par rapport au coût cible (100k€), l’honoraire cible de 20k€ devra être ajusté en fonction. Par exemple, si les coûts du fournisseur sont de 80k€, alors la variable d’ajustement serait (100k€-80k€) x 25% = 5k€, ainsi, pour 80k€ de coûts, les honoraires du fournisseur seraient de 25k€. En revanche, dans ce type de contrat, le client ne paiera pas plus que le prix plafond, ce qui peut priver le fournisseur de tout

profit, voire même lui faire encourir des pertes. En effet, à partir d’un certain coût que l’on appelle le Point de Prise en charge Totale [Point of Total Assumption (PTA)], le ratio client/fournisseur cesse d’exister, et tout euro de plus dans les coûts du fournisseur devra être déboursé par lui, tandis que le prix à payer par le client au fournisseur serait toujours le même prix plafond. Le PTA se calcule comme suit :

Dans l’exemple ci-dessous, le prix plafond est de 150k€, ainsi les coûts

à partir desquels le fournisseur doit se prendre en charge sont de 140k€. Toute dépense du fournisseur au-delà de cette somme sera prise en charge totalement par lui-même.

Exemple 98: Contrat à prix fixe avec

intéressement

Comparaison des risques entre contrat à coûts remboursables et contrat à prix fixe Les risques varient selon le type de contrat. La figure ci-dessous montre que le risque est plus élevé, pour le fournisseur, avec un contrat à prix fixe et, pour le client, avec un contrat de type à coûts remboursables. On peut constater les suivants : Partage des risques : le contrat en régie avec intéressement (CPIF) représente le type de contrat où le partage des risques est le plus équilibré ;

Risques supportés par le fournisseur avec un contrat à prix fixe : dans ce type de contrat, le fournisseur a la plus grande part du risque. Si le projet n’a pas été vendu à perte dès le départ, la marge de profit peut être très avantageuse pour le fournisseur. En effet, il a avantage à réduire les coûts et à se montrer performant car la marge entre le prix convenu et le coût réel du projet deviendra son profit. Ce type de contrat est généralement utilisé lorsque les spécifications du projet sont bien définies, car on sait donc qu’il n’y aura pas de surprise pour livrer le projet. Si jamais, pour une

raison ou une autre, le service, le résultat ou le produit fourni par le fournisseur ne rencontrait pas la satisfaction du client, toute révision et réparation jusqu’à atteindre la satisfaction du client seront à la charge du fournisseur. Par exemple, comme le « Time-to-Market » est de plus en plus court, certains produits sont vendus aux clients sans même être testés : ainsi, même si les spécifications sont claires, si le produit ne répond pas aux attentes du client, le fournisseur doit prendre en charge le coût des heures de troubleshooting, voire de développement du produit jusqu’à

satisfaire le besoin du client. Dans la plupart des contrats à prix fixe, le fournisseur risque également de payer des pénalités en fonction du nombre de jours de retard ;

Figure 46: Comparaison des risques selon le type de contrat

Risque supporté par le client avec un contrat à coûts remboursables : dans ce type de contrat, une haute part du risque échoit au client car il n’est pas à l’abri du fournisseur qui met du temps à livrer le projet juste pour augmenter ses coûts, et par conséquent pour augmenter ses profits. Par contre, comparativement au contrat de type coûts remboursables avec pourcentage des coûts, le fournisseur n'a aucun avantage à augmenter le prix du contrat puisque que son profit est fixe. Par contre, il n'y a pas d'avantage à les diminuer non plus.

Le client devra donc s'assurer un contrôle des coûts du projet.

Manager les approvisi Les organisations dotées d’une culture de management ont leur propre guide de méthodologie pour le management des fournisseurs de services ou de produits sur un projet. Les autres improvisent ou comptent sur le savoir-faire du Manager de Projet.

Exemple 99 : le fournisseur intervient durant la phase de design et d'implémentation du client

En général, dans le cas où le fournisseur fournit un service, le Manager de Projet est amené à manager les suivants : La relation contractuelle avec le fournisseur : le Manager de Projet manage le contrat avec le fournisseur, comme la facturation ou tout éventuel changement du scope du fournisseur sur son intervention sur le projet qui a un impact sur le contrat signé ; Le suivi opérationnel : le Manager de Projet s’assure de l’avancement, de la livraison dans le respect des délais, des coûts, des contraintes

techniques et de qualités définies ; La performance du fournisseur sur le projet : le Manager de Projet peut mettre en place un système de métrique (KPI, par exemple) afin d’évaluer régulièrement la performance du fournisseur ; Les escalades avec le fournisseur si celui-ci ne performe pas comme prévu dans le contrat.

Clore les approvisionn

Il faut toujours clore proprement les contrats avec les fournisseurs. Il est parfois très tentant de se serrer juste la main et de se dire au revoir, mais un certain nombre de tâches doivent être effectuées et, notamment, il faut que le Manager de Projet s’assure de la réalisation des tâches suivants : 1. Les livrables du fournisseur sont validés et acceptés, ce qui permet de finaliser la participation du fournisseur au projet. S’il y a rupture de contrat, à l’amiable ou pas, s’assurer que l’on récupère les livrables du fournisseur même s’ils ne sont pas finalisés ;

2. La facturation : le Manager de Projet doit s’assurer que le fournisseur est payé selon les accords du contrat et qu’il ne reste pas de dû en suspens ; 3. Le Manager de Projet doit organiser une session de lessons learned avec le fournisseur pour savoir ce qui a bien et moins bien marché. Cette session de retour d’expérience est nécessaire si l’organisation veut s’améliorer dans le futur dans le management de ses fournisseurs. Une organisation qui valorise l’amélioration de sa méthodologie de projet oblige son Manager de Projet à toujours documenter les retours d’expériences et les leçons apprises

des projets effectués.

L’application de connaissances nécessite le management efficace de processus appropriés Comme nous l’apprend la définition ci-

dessus, le management de projet est l’application efficace de chacun des domaines de connaissance, qui sont euxmêmes constitués de processus. Autrement dit, le management de projet revient à un management efficace des processus appropriés composant chaque domaine de connaissance. Un processus est un ensemble d’actions et d’activités en relation les unes avec les autres, menées à bien pour aboutir à un ensemble prédéfini de produits, de

services ou de résultats. Les processus de management de projets sont exécutés par l’équipe projet. (PMBoK®) Définition 15: Processus

Ceux qui connaissent bien la 4ème édition du PMBoK® auront retrouvé les mêmes 42 processus répartis dans les différents domaines de connaissance que nous avons pu voir dans la section précédente. Ces 42 processus sont nécessaires au management de projet et sont répartis en cinq groupes de processus.

Groupe de processus de Démarrage (2 processus) Il faut démarrer le projet à un moment précis. Un démarrage propre du projet consiste à appliquer efficacement ce groupe de processus qui reprend les actions et activités permettant de définir le début d’un projet. Cela comprend par exemple la nomination du Manager de Projet, l’autorisation d’engager les ressources ou encore le budget nécessaire pour réaliser le projet.

Figure 47: Groupe de processus de démarrage (Source : PMBoK®)

Groupe de processus de Planification (20 processus) Une fois que le projet est autorisé à démarrer, une multitude d’informations diverses vient saturer le Manager de Projet. Il doit alors veiller à avoir une approche structurée de manière à ne pas être submergé par les événements, ce qui risquerait de faire échouer le projet. Ce groupe de processus de management de projet comprend les actions et activités qui permettent d’élaborer le scope du projet, d’affiner les objectifs et de définir la suite des actions nécessaires pour atteindre les objectifs fixés.

Figure 48: Groupe de processus de planification (Source : PMBoK®)

Groupe de processus d’Exécution (8 processus) Certains préfèrent exécuter tout de suite le projet sans avoir pris le temps de le planifier correctement. D'autres passent leur temps à planifier sans oser entreprendre l’exécution du projet. Il faut trouver un équilibre entre ces deux approches car, comme nous le verrons plus tard, on revient toujours à replanifier et ensuite à exécuter ce que l'on vient de planifier. Cela suppose une bonne connaissance des processus d’exécution d’un projet.

Ce groupe de processus comprend les actions et activités qui permettent d’exécuter le projet tel que défini dans le processus de planification.

Figure 49: Groupe de processus exécution (Source : PMBoK®)

Groupe de processus de Contrôle et de Surveillance (10 processus) Premièrement, on planifie. Ensuite, on exécute ce que l'on vient de planifier. Enfin, on contrôle ce que l'on a exécuté. Le fait de contrôler et de surveiller constamment ce que l'on fait permet d’éviter toute dérive lors de la réalisation du projet. Ce groupe de processus de management de projet permet de suivre les progrès du projet ainsi que de revoir et de réguler son avancement et sa performance,

d’identifier les parties pour lesquelles des modifications du plan s’avèrent nécessaires et d’entreprendre les rectifications correspondantes.

Figure 50: Groupe de processus de contrôle et suivi de projet (Source : PMBoK®)

Groupe de processus de clôture (2 processus)

Figure 51: Groupe de processus de clôture de projet (Source : PMBoK®)

Certains managers de projet pensent que

le projet est terminé lorsque la dernière livraison a été effectuée. Pour d’autres, c’est la facturation au client de la dernière livraison qui marque la fin du projet. Il faut éviter de se précipiter et d'estimer trop rapidement le projet terminé : il est nécessaire de le clôturer proprement. Ce groupe de processus comprend les actions et activités qui permettent aussi bien de finaliser toutes les phases engagées pour mener à bien le projet que de clore formellement le projet.

Elaboration sur mesure L’application de ces processus ne doit pas se faire de manière équivalente pour tous les projets : chaque projet est

unique et il va de la responsabilité du Manager de Projet et de son équipe d’appliquer les processus appropriés avec la rigueur adéquate. Il ne sert par exemple à rien d’alourdir le management d’un projet à petit budget, car cela peut le freiner ainsi que provoquer un surcoût. La méthodologie et par conséquent, les processus qui la composent, doivent être customisés en fonction du type de projet. Par exemple, selon sa taille, sa complexité ou les revenus qu'il générera.

Les phases de projet ne sont pas les groupes de processus de management

Ces groupes de processus ne représentent en aucun cas les phases du projet, bien qu'ils doivent s’enchaîner comme montré dans la figure cidessous :

Figure 52: La relation entre les 5 groupes de processus

Les phases du projet ne sont pas les

groupes de processus du management de projet, elles sont les divisions à l’intérieur d’un projet qui offrent un meilleur point de contrôle à chaque fin de phase pour permettre de diriger le projet de façon efficace. En effet, sur un projet plus complexe, la séquence du groupe de processus peut être répétée dans chaque phase, comme montré dans l’exemple ci-dessous.

Exemple 100: Phases vs Groupes de processus – customisation d’une méthodologie

Nous pouvons observer dans cet exemple que, dès la phase 1 d’initiation, les groupes de processus de démarrage et de planification sont présents. On peut également remarquer que l'ensemble des 42 processus ne sera pas appliqué pour le projet. Ceci est un exemple typique de customisation de méthodologie ou l’on ne considère que les processus que l’on estime nécessaires à la réalisation du projet. On peut remarquer également l’utilisation des « portes d’étapes » dans cette méthodologie adaptée aux besoins

du projet, qui empêchent de passer à l’étape suivante si celle qui la précède n’a pas donné entière satisfaction.

Figure 53: compétences d'un Manager de Projet "gold" – les 10 commandements

Le management de projet est l’application de compétences « Un homme compétent est un homme qui se trompe selon les règles. » Paul Valéry Le management de projet est aussi l’application des compétences aux activités d’un projet pour en satisfaire les exigences. Ces compétences du Manager de Projet ne sont pas que la

somme des domaines de connaissance en management de projet que l’on a vu dans la section précédente, elles relèvent aussi de leur combinaison, des potentiels de la personne et de la performance ; facteur principal de réussite. Dans les couloirs, pendant les pauses ou encore au moment du repas ou de l’apéritif, j’ai eu la curiosité de poser, à toutes les personnes que j’ai croisées lors d’un congrès PMI® sur le Management de projet en mai 2010 à Milan, la question des compétences que devrait pouvoir démontrer un Manager de Projet. Tous s’accordaient à dire, de dans l'absolu, un Manager de Projet

devait pouvoir toucher à peu près à tout. Cela peut paraître effrayant lorsque ce n’est pas notre cas, mais que l’on se rassure, ces personnalités savent aussi que personne ne peut être parfait ni aussi complet, comme dit l’adage. L’une d’elles releva qu’un Manager de Projet doit pouvoir posséder une capacité d'analyse avec attention donnée aux détails, sans toutefois trop s’y arrêter. Une autre précisa que le Manager de Projet devait pouvoir démontrer une capacité à manager les situations incertaines et avoir la capacité de prendre un certain nombre de décisions sans disposer de toutes les informations, surtout quand elles sont conflictuelles. D’autres encore mentionnèrent la

capacité relationnelle, la capacité à négocier et déléguer et une grande disponibilité malgré une charge de travail déjà importante. En somme, en posant la question à plusieurs professionnels du management de projet, on peut conclure qu’un Manager de Projet doit pouvoir cumuler un large spectre de compétences aussi bien techniques qu’interpersonnelles. Ceci est rarement le cas dans la réalité, car le Manager de Projet a ses atouts et ses faiblesses, comme tout le monde. Toutefois, pour mener à bien leurs projets, les managers de projet devraient continuellement chercher à combler leurs lacunes en acquérant d’autres compétences, en fortifiant leurs points

forts et en pensant ainsi constamment à leur développement personnel. En fin de congrès, en relisant mes notes dans l’avion du retour, j’ai établi mon top 10 des dispositions, capacités et aptitudes spécifiques importantes que le Manager de Projet devrait pouvoir posséder. Cette liste, totalement subjective et loin d’être exhaustive, comporte néanmoins l’essentiel à mes yeux pour mener à bien le projet dans la bonne ambiance et en toute honnêteté et transparence. Chacun peut disposer de sa propre liste, mais il vous sera aisé, à mon sens, de trouver un point de convergence entre la vôtre et celle de l’auteur, votre humble serviteur.

Mon top 10 des compétences à posséder est le suivant : 1. Connaissances et performance en management de projet 2. Fort leadership 3. Bonne communication et sens aigu de la relation humaine 4. Passion et croyance 5. Enthousiasme communicatif 6. Capacité à prendre des décisions 7. Sens aigu du détail 8. Maturité émotionnelle 9. Compétences managériales 10. Responsabilité, intégrité et honnêteté Ces compétences identifiées sont somme toute génériques et se doivent

d’apparaître dans tout métier. Leur approfondissement permettra au Manager de Projet de pouvoir penser et agir de manière efficace dans le management de son projet. Certaines caractéristiques des compétences citées portent sur les traits de personnalité des managers de projet et de leur motivation, d’autres sur leur habileté sociale à gérer leurs propres tâches tout en maintenant un bon climat au sein des stakeholders et de l’équipe projet. En effet, ces compétences sociales interviennent dans sa relation et son interaction avec tous les acteurs du projet. On ne le mentionnera jamais assez, mais le Manager de Projet obtient

des résultats grâce à ses ressources et à son influence sur les stakeholders et, par conséquent, grâce à son application efficace de ces compétences qui représente tout l’art du management de projet. Au sens étymologique du terme, l’art est la manière de disposer, de composer habilement avec les gens. Le management de projet implique un savoir-faire, une habilité qui n’est pas pure application de techniques et de processus acquis, mais qui suppose également d’autres compétences sociales qui ne sont autres que l’art d’interagir et d’inspirer les autres, d’insuffler enthousiasme et la motivation en faisant preuve de maturité émotionnelle. La réussite d’un projet

dépend des personnes (équipe projet et stakeholders) et de la capacité du Manager de Projet à entrer en relation avec elles et à en tirer le maximum du potentiel de la relation. Je n’ai encore jamais croisé de Manager de Projet disposant de l’entièreté des compétences citées. D’où l’importance de chercher à s’améliorer tout en s’entourant des personnes qui nous sont complémentaires. En montant une équipe projet, on prend en compte cette complémentarité au niveau des compétences : personne ne peut parvenir à être aussi performant qu’un groupe de personnes réunies.

Chacun des lecteurs peut dresser la liste de ses points forts et faibles par rapport aux compétences mentionnées en complétant le tableau suivant : Mes atouts

Je maîtrise ces compétences

Je peu ces co

De par sa formation, le Manager de Projet hérite de connaissances théoriques sur la science du management de projet. Il y a appris entre autres la manière de manager les risques ou de dresser un planning. Mais l’art du management de projet, l’art de composer avec les autres, les compétences que l’on cherche à développer dans cette

section, ne s’apprennent pas dans les livres. Elles peuvent être innées chez certains, comme s’avérer beaucoup moins naturelles chez d’autres. Néanmoins on peut les développer au travers de l'observation et du modelage de personnalités particulièrement douées que nous avons pu observer au travail, dans les workshops, autour de soi, à la télé, etc. « La vie journalière en enseigne plus que le livre le plus propre à exercer une influence. » Goethe Plus que les livres et les formations, c’est la vie qui nous

enseigne, par notre expérience ou celle des autres, de lire entre les lignes, de détecter les vibrations, bonnes ou mauvaises, de déceler qui est déconnecté du projet, qui n’y croit plus, qui n’est pas heureux sur le projet, et d’agir en conséquence ; cela même lorsque l’équipe est virtuelle et que les communications ne se font que par vidéo ou audioconférence. On n’apprend pas dans les livres comment flairer, comment détecter qu’un membre de l’équipe se sent seul ou abandonné sur un projet, ce qui peut affecter la collaboration. On dit que 90% de la communication est verbale, or les équipes sont de plus en plus virtuelles et

la communication réglée souvent par courrier électronique. On ne se croise plus dans les couloirs mais lors de vidéoconférences. On sait pourtant que certaines personnes ont tendance à penser au pire des scénarios quand elles travaillent en solitaires, d’où l’art de composer avec les autres. Manager un projet ne revient pas seulement à manager le budget et le délai, mais également à manager les personnes qui effectuent des tâches du projet virtuellement ou au sein de la société, ce qui demande des compétences. Cette section a pour objectif de donner un aperçu de l’art du management de projet, de l’art d’obtenir des autres

ce qu’on leur demande de faire. Les managers de projet ne sont pas appelés sur un projet pour leur expertise technique. Ils sont là pour leur savoirfaire en management de projet, à savoir, organiser, communiquer, faciliter la vie des autres pour faire en sorte que le projet évolue. Si les processus que l’on a cités plus haut sont aisés à apprendre lors de formations, les compétences dont on parlera ci-dessous ne s’acquièrent pas du jour au lendemain. Seule la pratique quotidienne ou l’observation d’experts en ce domaine garantit que l’on s’améliore pour maximiser le potentiel de toute relation avec les autres.

Performance en

Management de projet La performance est le facteur principal de la réussite. Elle se caractérise par une bonne compréhension et une pratique efficace et pragmatique des connaissances, des compétences, des outils et des techniques qui sont reconnus comme utiles pour manager un projet. Il est donc capital d’acquérir les connaissances indispensables pour l’utilisation des concepts et des méthodes de management de projet. Ainsi, il est nécessaire de connaître au moins l’une des méthodologies reconnues comme « de bonne pratique » telles que, pour n’en citer que certaines:

la méthodologie proposée par PMI® dans le PMBOK®, née aux États-Unis dans les années 60 ; ou la méthodologie Prince 2 créée en Grande-Bretagne dans les années 70 par l’OGC (Office of Government Commerce) ; ou le CMMi, mis au point dans les années 80 aux États-Unis par le département de la défense ; ou encore le Six Sigma de Motorola, devenu très célèbre dans les années 90 lorsque le groupe General Electric, présidé par Jack Welsh, décida de l’appliquer et de l’améliorer. Il faut savoir que chacune de ces

méthodologies comporte ses propres règles de certification. On peut être certifié Prince 2 Fondamental ou Practitioner ; Black Belt pour 6 Sigma ; CAPM ou PMP ou PgMP avec PMI®, etc. Pour chacune de ces certifications, il faut présenter des examens et assister à des séminaires professionnels. Les certifications sont d’ailleurs devenues une exigence courante dans les grands groupes internationaux. Il est très important de ne pas se cantonner à une seule méthodologie et de veiller à toutes les comprendre, même si l’on n’est pas spécialiste de chacune d’entre elles. En effet, pour être performant, il est nécessaire d’élaborer

pour chaque type de projet une méthodologie appropriée, sur base de l’application efficace des connaissances assimilées. Le rôle du Manager de Projet est d’adapter au cas par cas une méthodologie performante, en se basant soit sur la méthodologie en rigueur dans sa compagnie, soit sur des méthodologies standards ou sur de meilleures pratiques du marché. Il devient alors évident que la connaissance des processus de management est une compétence incontournable pour quiconque veut manager un projet. Cependant, une parfaite maîtrise de la théorie n’est rien si l’on ne sait la mettre

en pratique : un excellent théoricien qui n’est que médiocre en pratique devrait se contenter d’enseigner ou d’écrire des livres plutôt que de réellement diriger des projets. A contrario, un manager qui a de l’expérience et des connaissances en management de projet, qui ne se laisse pas emprisonner dans une seule méthodologie et qui aborde de manière pragmatique la gestion de son projet, va contribuer à la réussite du projet qu’il dirige. « L’expérience est le nom que chacun donne à ses erreurs. » Oscar Wilde Voilà pourquoi il faut toujours qu’un

Manager de Projet junior soit accompagné d’un mentor expérimenté pour l’aider dans cette tâche : n’ayant pas encore traversé son propre désert ni subit les inévitables tempêtes et orages qui jalonnent le management d’un projet, il se retrouverait désarmé face à une situation de crise et son inexpérience pourrait être fatale au projet.

Un sens du leadership “Le leadership est comme la beauté, difficile à définir. Mais lorsque vous la rencontrez vous la reconnaissez.” Warren Bennis Les managers de projet se doivent d’être des leaders. Ils sont les architectes et les responsables de la réussite ou de l'échec d'un projet.

Un leader proactif Un Manager de Projet doit être proactif et non pas réactif. En s'appuyant sur une vision claire des objectifs à atteindre et du chemin à parcourir pour y parvenir, il

doit fédérer une équipe autour de son projet et créer une émulation positive, propice à l'émergence de l'intelligence collective au sein d'un groupe de travail.

Figure 54: Manager de Projet leader avec vision et influence

Un leader avec une vision Il est important de croire en cette vision de la marche à suivre et d'obtenir la confiance de son groupe de travail : si l'on oblige une équipe à se plonger dans une approche qui ne convainc pas, on condamne le projet à l'échec.

Apprendre à être leader en faisant “Le leadership est comparable à la forme physique: tout le monde ne peut pas être un athlète olympique, mais chacun peut améliorer sa forme physique.” Noel Tichy Certains managers de projet sont des leaders naturels qui arrivent à obtenir facilement l'adhésion des autres. Si ce trait de caractère n'est pas inné, il est toujours possible de l'acquérir. Cela se

traduit par des actions quotidiennes : il est important de montrer l'exemple, de mettre la main à la pâte, d'inspirer les autres et de les pousser à s'investir dans la réalisation du projet. Le vrai leader n’hésite pas à se mettre au service de son équipe, même si cela peut sembler vil ou rabaissant pour certaines personnes pour qui la position hiérarchique importe plus.

Un leader disponible Le vrai leader voit son équipe comme l'ensemble des contributeurs au projet qu'il mène, mais aussi et surtout comme des êtres humains. Lorsque l'on considère son équipe comme prioritaire, tout le reste s'ensuit. Il faut être disponible et consacrer le temps

nécessaire à la bonne conduite du projet. Il faut également s'investir personnellement et prendre en considération les requêtes de ses coéquipiers.

Un leader avec de l’assurance personnelle La confiance en soi est aussi un élément clé pour le Manager de Projet : seuls les leaders qui ont confiance en eux accroissent le pouvoir de leur équipe. Il ne faut pas avoir peur de perdre sa place. Mais pour autant, le manager doit toujours mettre son équipe en avant et ne pas hésiter à s'effacer pour que les honneurs reviennent au groupe. Il faut penser « nous » et non plus « je ». Le

leader doit être doté de la capacité d’avoir confiance en lui sans le faire remarquer. Aux grands discours, il doit préférer la simplicité, une ligne directrice claire, des plans simples et des objectifs SMART. Le Manager de Projet est souvent perçu comme le membre le plus « stupide » de l’équipe. En effet, les autres membres sont supposés être experts dans leurs domaines. Sur un même projet, le manager peut avoir des scientifiques éminents, des architectes célèbres, des membres considérés comme des génies dans leurs domaines. Il doit alors être capable de faire preuve de leadership pour conduire son équipe à livrer le résultat escompté. Pour cela, il faut qu'il

se positionne comme le promoteur de la vision et du chemin à suivre qui mènera au succès du projet : l’équipe suivra facilement un leader performant, qui sait donner une direction claire et qui n’est pas brouillon dans sa manière de procéder.

Un leader synergique Il faut être un leader « synergique » dans le sens décrit par Robert Blake et Jane Mouton dans leur livre Les deux dimensions du management, aux Éditions d’Organisation - voir figure cidessous).

Figure 55: Style de leadership de Blake et Mouton

Le Manager de Projet doit être un leader synergique (ou optimisateur) avec un style correspondant à la zone 9/9. Il s'agit d'une personne qui sait combiner le relationnel et la productivité : elle parvient à avoir une bonne relation d’entente avec tout le monde, tout en assurant la productivité du groupe. Inversement, si l’équipe chargée du projet n’apprécie pas le leader ou ne comprend pas sa vision, elle aura du mal à le suivre et donc à être performante. L’état d’esprit engendre la performance. Le lecteur peut voir ci-dessous les

autres styles de management : Le style (1/1) : non productif avec un relationnel pauvre. Il nous est à tous arrivé de croiser un jour un bureaucrate avec ce style de leadership. Ces personnes sont souvent antipathiques et peu efficaces au travail. Loin de moi l'idée qu’ils représentent les fonctionnaires travaillant dans les services publics : pour en avoir déjà rencontré beaucoup, ils sont loin d’adopter ce style. Le style (9/1) : très productif avec un relationnel pauvre. Le Manager de Projet correspondant à ce style est un dictateur et la relation avec son

équipe fonctionne grâce à la peur qu'il suscite. Il obtient des résultats en s’affirmant, en donnant des ordres et en sanctionnant lorsque ces derniers ne sont pas exécutés. Ce type de leader n’a que faire des relations humaines et considère son équipe comme un simple outil pour faire aboutir le projet. Cela me rappelle l’armée. Le style (1/9) : non productif avec un très bon relationnel. Le Manager de Projet n’a aucune autorité et son seul objectif est de réussir à bien s’entendre avec tout le monde. Ce type de leader ne supportera pas les conflits, tentera de les éviter par

crainte de ne plus être aimé ou de contrarier un membre de son équipe. Le style (5/5) : mi-productif avec un relationnel moyen. Ce Manager de Projet négocie continuellement et veut toujours faire des compromis : la productivité au détriment du relationnel et vice versa. Il hésite en permanence quant à la marche à suivre et veut avancer sans frustrer personne. Les conséquences de cette manière de fonctionner se répercutent sur la productivité et sur le relationnel. C’est le genre de leader ni-ni, qui ne sera ni à gauche ni à droite, ni froid ni chaud. Les résultats quant à eux ne seront ni bon ni

mauvais, tout comme le relationnel...

Un leader par l’exemple « Leadership is the art of getting someone else to do something you want done because he wants to do it.» Dwight D. Eisenhower Le Manager de Projet doit continuellement montrer l’exemple, surtout dans les moments les plus difficiles où le projet est remis en question et où l’équipe est au bord de la rupture. Il se doit d'être persévérant. C'est lui qui, lorsque le projet se trouve dans une impasse, doit trouver de nouvelles solutions tout en maintenant le cap établi. Il doit faire preuve de son

aptitude à établir un ordre des priorités, à témoigner du respect et de l’éthique et à tendre vers l’excellence. Un projet médiocre ne peut être une option pour un véritable Manager de Projet. Le Manager de Projet doit aussi être visionnaire tout en étant pragmatique. Il balise les étapes du chemin à court terme mais aussi à long terme. Le Manager de Projet doit cultiver la résilience par le biais de stratégies cognitives, comportementales et relationnels.

Un leader avec de l’influence De plus, le Manager de Projet doit être la personne d'influence grâce à qui l'objectif sera atteint. Le Manager de

Projet doit avoir la capacité à influencer des personnes pour qu’elles agissent d’une certaine façon et qu’elles atteignent des buts communs. En effet, comme le dit John C Maxwell, le leadership n’est ni plus ni moins qu'une question d'influence. Ainsi, le manager doit avoir de l’influence sur les acteurs du projet mais aussi sur toutes les personnes qui gravitent autour : les gens « d’en haut » (directeurs de programme, vice président ou CEO de la compagnie, etc.), les gens « d’en bas » (l’équipe projet et ceux qui contribuent au projet), et les gens « à son niveau » (ses pairs en management de projets). En fait, la principale difficulté du Manager de

Projet est de parvenir à mobiliser des acteurs sur lesquels il n'a pas forcément de pouvoir formel. Plus son pouvoir de leadership est fort et étendu, plus il aura une influence positive sur la performance de son équipe, mais aussi sur les stakeholders, ces parties prenantes dont les demandes quant au projet sont toujours exigeantes. Parallèlement, un Manager de Projet sans sens du leadership aura une influence moindre, une autorité insuffisante sur son équipe, et cela se traduira par une mauvaise performance au final. Voilà pourquoi un bon sens du leadership détermine le succès d’un projet.

Un leader qui inspire « You don’t manage people in a battle; you lead people in a battle» Anonyme Le Manager de Projet doit être le leader capable de créer une ambiance de travail positive. Il doit inspirer le respect en prenant en main la responsabilité du projet et en dessinant une vision claire et pragmatique de la direction à suivre. Il ne doit pas se targuer d'être celui qui contrôle, mais plutôt celui qui inspire, celui qui prépare pour son équipe un chemin agréable à suivre, sans obstacle à craindre. Le Manager de Projet doit avoir la capacité d’inspirer son équipe à prendre une voie, même s’il s’agit de

celle qui est la moins traversée mais qui fait toute la différence. En effet, le Manager de Projet doit savoir par moment se libérer du conformisme social, des sentiers battus, en osant affirmer ses différences dans ses choix. Il y a deux manières d’amener une personne à accomplir une mission : soit en utilisant la force ou la menace, soit en suscitant le désir de remplir la tâche confiée. Le Manager de Projet doit être quelqu’un qui attire les talents et pour cela, il doit être apprécié par son équipe et donner envie de travailler sur son projet. Enfin, les leaders attirent les gens de manière irrésistible. Si personne ne veut travailler sur votre projet, c'est que vous

n'êtes pas considéré comme un leader.

Un sens aigu du détail « La chance n’existe pas : ce que vous appelez chance c’est l’attention aux détails. » Sir Winston CHURCHILL Même si cela peut sembler paradoxal, le Manager de Projet doit démontrer sa capacité de prendre en compte chaque détail, tout en ne s’enfermant pas dans le micro-management de ces détails. Tel l’effet papillon, le moindre détail qui n’a pas été pris en considération peut avoir un impact majeur sur l’entièreté du projet. Selon la loi de Wilfredo Pareto, dans une large majorité de situations, 20% des facteurs suffisent

à expliquer 80% des résultats. Il faut donc prendre garde à tous ces facteurs qui ont une influence cruciale sur le résultat final. Face à cette répartition inégale, il est important que le Manager de Projet sache établir un ordre des priorités. De cette manière, il pourra focaliser son attention sur les phénomènes à résoudre. Sens du Détail sur l’accident de Challenger en 1986 En janvier 1986, la navette spatiale américaine Challenger s'est désintégrée après seulement 73 secondes de vol alors qu'elle évoluait à 3 200 km/h. Les joints toriques de l’un des deux propulseurs à poudre accolés au

réservoir principal d'hydrogène n’avaient pas été testés en conditions de grand froid car les concepteurs considéraient que le lieu de tir la Floride - bénéficiait d'un climat toujours ensoleillé. Le fait est qu'un phénomène météorologique touchant assez fréquemment la Floride avait fait descendre la température bien en dessous de 0 °C au cours de la nuit précédant le tir. Un détail oublié qui a fait toute la différence… Exemple 101: Sens aigu du moindre détail

Historicité du projet et connaissance de l’équipe Tout en restant concentré sur l’objectif final, le Manager de Projet doit avoir la capacité d’être au courant de tous les

détails de chacune des phases (initiation, design, déploiement, etc.), pour chaque activité ou tâches qui la composent. Il doit démontrer son aptitude à comprendre les spécificités du projet sans pour autant prendre la place des experts-technique (le Manager de Projet est supposé être le membre le plus « stupide » de l’équipe projet, nous l’avons déjà dit). C’est d’ailleurs en portant une attention toute particulière aux détails du projet qu’il pourra combler ses lacunes techniques et mener à bien ce projet. Rappelons aussi qu’un Manager de Projet est recruté non pas pour son expertise technique, mais pour sa capacité à livrer un projet dans les temps et sans dépasser le budget prévu.

Voilà pourquoi il n’est pas rare que les membres de l’équipe rejettent la responsabilité sur leur Manager de Projet lorsque les choses se déroulent mal. Cette règle d’or quant à la maîtrise des détails du projet s’applique non seulement à la manière dont les phases sont interconnectées les unes aux autres, mais également à la façon dont elles sont mises en application et livrées. Rien ne doit être laissé au hasard (design, phases de tests, etc.). Le passage d’une étape à la suivante (stage gates) est le moment propice pour vérifier si rien n’a été omis dans l’étape où l’on se trouve, avant d’entamer l’étape suivante. En ce qui concerne son équipe, le Manager de Projet doit veiller à

comprendre en détail les rôles et responsabilités de chacun. Il doit également contribuer à ce que les collaborateurs sachent toujours à quoi sont occupés les autres : cela favorise l’esprit d’équipe et développe un sentiment de loyauté vis-à-vis du groupe. Au-delà de ces aspects, le Manager de Projet doit s’assurer que ses collaborateurs savent exactement ce que l’on attend d’eux, quelles sont leurs responsabilités ainsi que les détails du scope de leur travail. (Nous verrons plus loin comment il est possible de développer une matrice de responsabilité [RACI]). En résumé, le Manager de Projet se doit de posséder une « compétence

d’historicité », c’est-à-dire une fine connaissance des éléments historiques de son projet. Pour que cela soit possible, il doit être impliqué au quotidien dans son projet et maîtriser chaque détail sans pour autant – cela a été précisé plus haut – s’y enfermer. C’est pour cela que prendre les rênes d’un projet en arrivant en cours de route peut être un handicap pour un Manager de Projet : celui-ci n’aura pas la connaissance des faits antérieurs à son arrivée.

Figure 56: Manager de Projet avec un sens aigu du détail du début jusqu’à la fin du projet

« Nous sommes ce que nous répétons sans cesse. L'excellence n'est donc pas une action mais une habitude » Aristote

Intelligence relationnelle L’attention aux détails ne s’arrête pas uniquement aux tâches techniques. Elle concerne également la partie « ressources humaines ». En effet, le Manager de Projet doit pouvoir détecter les plus infimes détails ou signes (un geste, une phrase, un mot, un sourire forcé, de l’amertume etc.) qui

sont susceptibles de témoigner du détachement de certains membres de l’équipe, du manque d’intérêt personnel ou collectif quant au projet, du moral du groupe de travail, d’une ambiance délétère, etc. Afin de garder au beau fixe l’ambiance et le moral de l’équipe, de manière à ce que les collaborateurs restent motivés et concentrés sur le projet, il faut anticiper les tensions et les anxiétés en observant ces petits marqueurs extérieurs, de façon à pouvoir intervenir à chaque fois que cela est nécessaire. Le manager doit pouvoir repérer les individus qui se sentent isolés, ceux qui n’interviennent jamais, les sectaires ou les membres d’une équipe de projet qui sont égoïstes

et opportunistes, au détriment de l’équipe et du projet. Enfin, il doit savoir éjecter des projets les « terroristes psychologiques » qui génèrent la peur, répandent des rumeurs et sapent le moral du groupe. Un Manager de Projet doit toujours guetter ces signaux pour tenter de découvrir ce petit « quelque chose » dont a besoin son équipe pour améliorer sa performance ou, tout simplement, pour se sentir bien sur le projet. Pour cela, il a besoin de comprendre chaque individu qui compose son équipe. Cela ne signifie pas se contenter de connaître le prénom de chacun, de dire « bonjour » et « au revoir » ou de rajouter « s’il vous plaît » quand on fait

une demande. Tout cela fait partie des règles de bonne conduite (même si cela n’est pas évident pour tout le monde). Nous parlons ici de la communication à visage humain, des détails matériels (outils pour faire avancer le projet, etc.) et autres arrangements personnels (respect de la vie privée, horaires décents, etc.). Il s’agit aussi de prendre en considération les besoins des membres quant à l’avancement de leurs carrières. Le Manager de Projet ne doit pas non plus négliger de dire de manière explicite à son équipe que leurs efforts et leur travail sont appréciés, et de rappeler qu’il est avec eux sur le champ de bataille, même lorsque la situation est problématique et qu’il ne sait pas mieux

qu’eux comment la résoudre. Un bon Manager de Projet veille aussi à régler tous les détails pour faire en sorte que son équipe mette continuellement ses efforts, son temps, son attention et son énergie dans le projet, dans les meilleures conditions possibles. Certains managers de projet font preuve d'une grande aisance relationnelle (avec l’équipe chargée du projet, les stakeholders, les directeurs, etc.) et connaissent leur projet et leur équipe sur le bout des doigts. Se demander si cette compétence est innée ou acquise importe peu : il faut simplement acquérir et développer une conscience aigüe de l’importance des détails et de l’historique du projet et se comporter en

fonction de ces éléments. Les managers de projet qui prennent cela en considération sont alors capables de communiquer aux autres leurs souhaits tout en interprétant les messages verbaux ou non verbaux venant de leur équipe ou des stakeholders. Ils éprouvent du plaisir à être en réunion et à converser car ils savent qu’ils ne seront jamais pris de court. Ils sont également capables de répondre à des défis ou même à des provocations de la part de personnes extérieures (un client de mauvaise foi par exemple) d'une manière qui saura les apaiser plutôt que les enflammer, c’est-à-dire en énumérant les faits et les détails qui constituent ces faits.

Les managers de projet expérimentés savent également qu’il faut parfois beaucoup plus que des faits ou des statistiques pour convaincre. Mais une connaissance détaillée des faits est un atout, quoiqu’il arrive… Cela étant dit, il faut tout de même voir les choses pragmatiquement et reconnaître les situations où – même en présentant des faits appuyés par des données exactes, en disposant des meilleures ressources possible ou de la pleine et entière coopération de son équipe –, des éléments de politique interne entrent en jeu. Nous sommes en effet dans un système humain où chacun a ses propres intérêts et préfère parfois valoriser ou voir les choses

différemment. Le rôle du Manager de Projet est de présenter les faits dans les détails. Une fois son travail accompli, il doit laisser aux autres le soin de gérer les enjeux politiques.

Passion et foi dans le projet « Lorsque vous êtes passionné, vous pouvez faire preuve d’audace, parce que vous disposez de cet élan, de cet enthousiasme, de ce courage et de cette fièvre qui permettent de soulever des montagnes. » Richard Templar, Les 100 règles d’or du management. Un Manager de Projet doit savoir s’engager et croire en la vision du business et de l’organisation qu’il est censé représenter : c’est de cela que va dépendre la réussite même de son projet.

Il est toujours désolant de voir un Manager de Projet qui ne croit pas suffisamment en son projet et qui ne met dès lors aucune passion dans ce qu’il fait. Un projet n’a aucune chance d’aboutir si son manager est sceptique quant au succès du produit, du service ou du résultat qu’il doit livrer. Autrement dit, le Manager de Projet doit avoir foi en ses objectifs et en la marche à suivre pour les atteindre, même s’il peut arriver que le doute s’insinue pendant la réalisation du projet. Toutefois, malgré son enthousiasme, le Manager de Projet doit se montrer vigilant, réaliste et toujours garder un discours professionnel. En effet, il vaut mieux se garder la possibilité

d’annoncer des bonnes nouvelles plutôt que d’être contraint de se contredire a posteriori. Ainsi, il faut absolument éviter de faire de fausses promesses alors que l’on se sait parfaitement incapable de les respecter. L’un des facteurs de réussite du projet est le fait d’avoir à ses côtés des stakeholders, des exécutifs haut placés dans l’organisation qui soutiennent les objectifs à atteindre et ne doutent pas des perspectives que peut livrer le projet. Ces perspectives doivent être claires, simples et facilement compréhensibles. Surtout, elles ne doivent pas être artificiellement élaborées ou complexes. Par exemple, le projet ToIP a été lancé

dans le but de réduire, par un facteur, le coût de communication de l’entreprise. Citons également le projet ETC qui a été développé pour augmenter la productivité de l’équipe virtuelle tout en réduisant les coûts de voyage. * * * Dégager des perspectives consiste à anticiper ce que sera le futur si le projet est réalisé. Le Manager de Projet doit être le promoteur de ces perspectives et des objectifs à atteindre. Il doit convaincre un maximum de personnes et notamment ceux qui restent sceptiques quant aux bénéfices du projet. Il est en effet plus facile de réaliser un projet lorsque l’on bénéficie du soutien de

personnes qui croient aux valeurs prônées et lorsque tout le monde se rassemble pour aider à sa réalisation en offrant à tout moment support et contributions. En revanche, les personnes qui ne croient pas au projet ne le soutiendront évidemment pas ou, pire encore, feront tout pour empêcher sa réalisation. Il est aussi important de ne pas décevoir ceux qui cru au projet. Il est donc crucial de gérer correctement leurs attentes en termes de coûts, de temps, de qualité ou de fonctionnalité. Outre le fait de croire en son projet, le Manager de Projet doit aussi être passionné par ce qu’il fait, et pour ce faire, il doit être friand de résolution de problèmes. En effet, un

projet n’est rien d’autre qu’un problème à solutionner.

Figure 57: Un Manager de Projet dansant son projet avec foi et passion

Il est très important d’éprouver du plaisir à exercer son métier : les gens passionnés préfèrent souvent être positifs, quelle que soit la situation à laquelle ils sont confrontés. Manager un projet sans passion n’aide en rien à la réussite du projet… De manière générale, passer 8 heures par jour – voire plus – à s’occuper d’un travail pour lequel on ne ressent aucune affinité doit être particulièrement pénible : cela représente 250 jours sur les 365 que comporte une année ! C’est aussi particulièrement éprouvant mentalement et le recul de l’âge de la retraite doit, dans ces conditions, être perçu comme

un affront particulièrement injuste… Pour le management, cela est d’autant plus vrai qu’il n’y a jamais un moment de répit : il se passe toujours quelque chose de nouveau. À l’inverse d’un passionné du sexe, par exemple, qui – bien que très enthousiaste – ne cabriole pas 8 heures par jour, 5 jours par semaine (pour la simple raison que cela n’est pas son métier), le Manager de Projet doit être sur le terrain tous les jours. Dans ces conditions, subir son travail et guetter la retraite peut générer du stress, du doute, rendre amer et donner l’envie de passer à autre chose. Comment peut-on croire à un projet et le mener à bien dans de telles conditions ? « Tout le monde savait que c'était

impossible à faire. Puis un jour quelqu'un est arrivé qui ne le savait pas, et il l'a fait. » Winston CHURCHILL Enfin, si le manager ne croit pas en sa réussite avant même d’avoir commencé à réaliser le projet, ce dernier deviendra effectivement difficile à livrer. Et très vite, le management se transformera en un pénible chemin de croix, une traversée du désert en solitaire, où le doute viendra s’insinuer et le but paraîtra inatteignable. Pire, le manager risque de ne plus se sentir à la hauteur de sa mission et cette impression peut davantage compliquer la situation et rendre la tâche plus ardue encore. En

effet, lorsque le self estime du manager commence à faiblir, cela dresse de nouvelles barrières entre lui et le résultat à atteindre. En résumé, s’il fallait n’énoncer qu’un conseil, ce serait le suivant : il faut avoir foi en son projet et en la manière dont on compte le réaliser, et il faut continuellement essayer de rallier les autres à sa cause.

Enthousiasme, congruence et résilience On dit souvent que rien de grand n’a jamais été réalisé sans enthousiasme et que c’est là l’apanage de toutes les grandes œuvres. Voilà pourquoi le Manager de Projet

doit être le catalyseur d’une dynamique. En effet, rien ne vaut ces moments où le dynamisme et l’enthousiasme sont à leur paroxysme et qu’un sentiment de toute puissance, d’invincibilité se développe pour permettre de traverser facilement toutes les tempêtes. Car des tempêtes, il en survient de manière imprévisible tout au long du projet : un manque de budget, une panne d’idées, un planning qui ne tient plus la route, des frasques du client, une équipe au bord de la déprime, etc. Le Manager de Projet doit également être capable de communiquer à son équipe son enthousiasme de la vie de tous les jours et son désir d’exceller. Lorsque son enthousiasme est communicatif, toute l’équipe chargée du

projet peut en bénéficier et cela influe positivement sur le projet : un individu enthousiaste peut se révéler et développer ses meilleurs dons. Le Manager de Projet doit posséder la compétence indispensable de pouvoir entraîner son équipe sans faillir, avec enthousiasme et esprit combatif. À l’inverse, s’il n’entretient pas la flamme en lui, il ne pourra pas enflammer les membres de son équipe.

Figure 58: Manager de Projet enthousiaste et congruent

Lorsque les collaborateurs sont libres de s’autogérer, tout en restant dans le cadre des processus mis en place, cela entretient un climat d’enthousiasme car chaque membre de l’équipe peut ainsi faire appel à sa propre créativité pour mener sa tâche, en bénéficiant d’une grande liberté. Il n’y a rien qui ne satisfasse plus une personne que lorsqu’elle peut diriger les choses à sa manière. Il est possible pour le manager de laisser une grande autonomie à son équipe tout en veillant à ce qu’elle suive les objectifs définis. On constate même

que plus on offre de l’autonomie à son équipe, plus elle tend à s’aligner avec les objectifs car cet alignement se fera toujours autour de ce qui est à achever. Chaque membre de l’équipe effectue alors sa tâche de manière autonome. Il faut éviter les micro-managements au sein de son équipe car les managers tombent souvent dans ce piège.

Les théories X et Y Le Manager de Projet doit éviter de verser dans la « théorie X » en dirigeant son équipe de manière autoritaire et en exerçant un contrôle normatif. Cette théorie suppose que l’équipe projet est passive, paresseuse, sans grandes ambitions, qu’elle redoute les

responsabilités et qu’elle préfère être dirigée. La bataille d’Iéna-Auerstedts le 14 octobre 1806 Ayant lieu pendant la Campagne de Prusse et de Pologne, cette bataille se termina par une victoire totale des Français, commandés par Napoléon, contre l’armée prussienne menée par Frédéric Le Grand, dont les guerres pourraient à elles seules remplir plusieurs volumes (elles sont d’ailleurs des classiques de l’art militaire). Cette armée prussienne a été la plus admirée et c'est elle qui eut le plus de succès en Europe. Dès lors cette défaite fut militairement décisive et psychologiquement

dévastatrice. . L'armée prussienne était une machine de guerre bien huilée, hautement centralisée et personne ne pouvait prendre une décision sans en avoir reçu l’ordre précis. Ceci correspond à la théorie X de Mac Gregor : l’armée obtenait des résultats en énonçant des ordres et ces ordres devaient être exécutés tels qu’ils avaient été donné, n’offrant aucune autonomie à la personne qui les exécutait. Au contraire, l’armée française de 1806, dont Napoléon a hérité lors de la Révolution, fut formée à partir d’une réserve de citoyens conscrits et motivés. Comme ils n'avaient pas eu le temps d'être formé à être des machines de guerre, ils s'engageaient

sur la ligne prussienne comme un essaim d’infanterie légère, de façon désordonnée et chacun combattait et agissait à sa convenance avec une grande autonomie, sans pour autant perdre de vue l’objectif final. À l’époque, la promotion était basée sur la performance. Dans les termes de Mac Gregor, cette armée française correspond à la théorie Y. Exemple 102: Théories X et Y

La théorie X fait référence à ces personnes qui ne font que leurs 35 heures, ni plus ni moins et qui ont constamment besoin d’être surveillées. Au contraire, le Manager de Projet devrait adopter la « théorie Y », faisant preuve d’un style de management qui laisse beaucoup plus d’autonomie à son

équipe, après avoir clairement défini avec elle les objectifs à atteindre. Douglas Mac Gregor, gourou en management qui a façonné dans son ouvrage The human side of enterprise (1960) les « théorie X et Y », suggère que l’application de la théorie Y entraîne généralement: une augmentation de l’efficacité et de la productivité ; une plus grande inventivité ; une utilisation plus complète des ressources que comporte l’équipe projet. C’est au Manager de Projet de ranimer et d’entretenir continuellement ce climat car il n’existe pas de situation plus difficile que celle de traîner une équipe

de projet sans motivation. Cela revient pratiquement à forcer quelqu’un à faire quelque chose contre son gré. Un bon Manager de Projet sait susciter et cultiver l’enthousiasme en adoptant une attitude positive, sans jamais se poser en victime. En effet, il ne peut se permettre de passer son temps à se plaindre des vicissitudes que comporte le projet, tout en contemplant le projet se faire sans lui. Il doit être le leader de son projet et non pas être à la traîne ou se faire porter par ses collaborateurs. Ainsi, se lamenter parce que l’on aurait préféré s’occuper d’un autre projet, ou que l’on souhaitait travailler dans une autre organisation ne peut pas être une attitude envisageable pour un manager en cours

du projet. Au contraire, nous le répétons, le Manager de Projet doit conserver une attitude positive qui déplace les montagnes. Et les montagnes à déplacer ne sont pas ce qu’il manque ! Assurer la bonne continuité du projet lorsque des membres clés de l’équipe démissionnent, par exemple, ou lorsqu’un client n’est pas satisfait du projet ou encore quand les stakeholders sont en conflit ouvert entre eux, etc. Dans pareilles situations, on attend du Manager de Projet qu’il déploie de l’énergie avec l’envie de grandir et de se développer avec le projet. Le Manager de Projet doit également cultiver un esprit congruent. Il se doit

d’être empathique et son sens aigu des détails, ou encore la pertinence de son intuition devraient lui permettre de percevoir avec exactitude les attentes et les sentiments de son entourage. Un Manager de Projet est congruent lorsque ses pensées, ses mots et ses actes sont en parfaite adéquation. Il est impossible d’être certain à 100% des hommes, du matériel, des fournisseurs, des délais ou du contexte. Mais le Manager de Projet doit montrer en toutes circonstances et avec beaucoup de ténacité qu’il est l'homme de la situation. Il doit, tous les jours, partir avec l’intention de dominer son sujet, son projet. Tout cela nécessite une intense préparation et ne peut

s’improviser au dernier moment. Même s’il est difficile d’être en permanence confiant et détendu, le Manager de Projet doit toujours rester optimiste. Devenir morne alors que l’on vit des heures sombres est bien la dernière chose dont a besoin le projet. La mélancolie et le stress sont contreproductifs et la meilleure manière de reprendre le dessus est de travailler en gardant sa bonne humeur et si possible son charme. Le Manager de Projet doit donc également être résilient dans son travail, en allant au bout de lui-même et sans tirer d’autre profit que la satisfaction d’avoir fait de son mieux, à tout moment, avec ses moyens. Il est important

d’éprouver du plaisir à livrer un travail bien fait. L’idéal serait de quitter tous les soirs son bureau en se disant qu’on a fait quelque chose de bien. Travailler dur tout en y prenant plaisir est possible. Enfin, plus important, le Manager de Projet qui est enthousiaste envers son projet devrait aussi l’être envers ses proches. On croise tellement de managers passionnés et enthousiastes au travail mais qui deviennent complètement renfermés ou aigris dans leur vie privée. Même si cela parait paradoxal – le contraire semble tellement plus courant ! – ce type de situation est monnaie courante. Il faut donc veiller à garder cet enthousiasme dans toutes les situations

auxquelles nous sommes confrontés, qu’elles soient personnelles ou professionnelles.

Capacité de prendre des décisions “On doit toujours peser ses décisions en fonction de l’opportunité des circonstances.” Sun Tzu Le rythme frénétique du management de projet ne permet pas au manager d’avoir du recul ou de revenir sur les choix parfois cornéliens auxquels il a été confronté dans l’exercice de ses fonctions. En effet, la nature de son travail l’amène à rencontrer

régulièrement des situations où il doit prendre des décisions difficiles qui engagent sa responsabilité et dont dépendent le résultat du projet. Ces décisions sont d’autant plus difficiles à prendre lorsqu’elles entrent en conflit d’intérêt avec certains stakeholders ou certains membres de l’équipe chargée du projet. Il y aura de nombreuses situations où le Manager de Projet devra agir en fonction de son propre jugement ou de son instinct, sans avoir toutes les informations en main. Il ne peut se contenter d’attendre une directive dictée par sa hiérarchie, qui n’arrivera peutêtre jamais. Il doit avoir la capacité de prendre des décisions décisives, quelle

que soit la manière dont il les prend – que cela soit à la suite d’un long travail d’évaluation ou d’une brève analyse. Quand une telle situation se présente, le manager doit savoir décider au moment opportun : il ne peut se permettre de fuir ses responsabilités ou de retarder l’échéance en hésitant sur la réponse à apporter au problème posé. La crainte de faire des erreurs ne peut servir de prétexte au manager qui recule devant une décision importante. En effet, la prise de risques est inhérente aux fonctions qu’il occupe, et il vaut mieux prendre une mauvaise décision que ne pas prendre de décision du tout.

Figure 59: Un Manager de Projet capable de prendre des décisions

Il n’y a rien de pire pour un projet que d’avoir un manager indécis dans ses intentions ou qui tente par tous les moyens de se décharger du poids de sa charge sur quelqu’un d’autre. En adoptant une telle attitude, le manager perd la confiance de son équipe et l’autorité qu’il avait sur elle car, à force de tergiverser sans oser assumer un choix clair, le projet n’avance plus. Un Manager de Projet doit donc être capable d’assumer des choix clairs, même dans un environnement incertain qui évolue constamment. Et au-delà de

cet aspect-là, il doit savoir transformer ses décisions en actions décisives pour permettre à son équipe de réaliser les objectifs du projet.

Causes d’erreurs les plus courantes dans la prise de décisions « Le faible a toujours des doutes avant de prendre une décision, le fort les a après. » Karl Krauss Voici une liste non-exhaustive des causes d’erreurs fondamentales les plus courantes dans la prise de décisions : ne pas prendre la décision de refuser un projet, alors qu’on devrait

la prendre ; décider de faire un projet quand rien ne le justifie ; prendre une mauvaise décision sur la justification du projet alors que celui-ci résout un faux problème ; prendre en compte le vrai problème, mais ne pas utiliser concrètement la solution ; ne pas bénéficier suffisamment de la participation de l’équipe projet dans les processus de prise de décisions et de résolutions.

Les différentes façons de prendre des décisions « Mieux vaut avoir suffisamment d’idées pour compenser celles qui

pourraient être mauvaises, que de ne jamais se tromper parce qu’on n’a pas d’idées. » Edward de Bono, Adepte de la pensée latérale Volontarisme Voici quelques manières basiques de prendre des décisions : L’autoritarisme : en dictant des ordres à son équipe, sans lui fournir beaucoup d’explications. On est dans la théorie X, avec une approche autoritaire et paternaliste où le Manager de Projet n’a même pas à justifier ses décisions auprès de son équipe.

La consultation : en prenant des décisions à la suite d’une série de consultations auprès d’experts, de membres de l’équipe, du PMO, des stakeholders, etc. Le consensus : en prenant des décisions collégiales où il arrive que personne ne soit satisfait à 100% des décisions prises car chacune des parties a dû faire des concessions pour atteindre un compromis, en mettant en balance les « avantages » et les « inconvénients » de la décision à prendre. L’un des moyens pour atteindre ce consensus est de présenter à l’équipe chargée du

projet, ou aux stakeholders, une série d’options viables, et de demander une évaluation de ces options en fonction des critères suivants : a. risques ; b. rapport coût et bénéfice ; c. capacité d’évolution de la technologie ; d. liste des avantages et inconvénients. La Loi du Guépard : en faisant appel à son instinct. Le Manager de Projet doit savoir appliquer la Loi du Guépard (Loi 1: Loi du Guépard capacité à prendre une décision) et développer l’art de la prise de décision en un clin d’œil. Cela ne

veut pas dire qu’il doit prendre des décisions sans réfléchir - cela parait évident et nécessaire -, mais il ne doit pas trop s’attarder à faire de longues analyses ou évaluations. Il faut qu’il soit capable de se jeter à l’eau, surtout lorsque la fenêtre de prise de décision est très étroite. En effet, il faut parfois se fier à son instinct. On pourrait objecter que le management de projet n’est pas comme l’art du poker, mais il faut savoir que les meilleures décisions sont parfois issues de l’instinct ou de l’intuition. La Loi du Guépard Le guépard est le mammifère

le plus rapide sur terre et il peut atteindre une vitesse entre 112 et 120km/h, avec une capacité à accélérer de 0 à 103km/h en 3 secondes seulement. Il utilise cette vitesse pour attraper ses proies. La Loi du guépard consiste à déclarer que les décisions rapides et décisives sont meilleures que celles issues de longues et interminables analyses. Selon le Chaos Manifesto du Groupe Standish, il a été démontré de manière empirique que les décisions rapides et décisives augmentent les chances de

réussite d’un projet Loi 5: Loi du Guépard - capacité à prendre une décision en un clin d’œil

Par exemple, imaginons que vous êtes le manager d’un projet qui a une forte probabilité d’être livré en retard car votre produit n’est pas encore au point et que votre département R&D ne vous a pas donné la date de disponibilité de ce produit qui est pourtant déjà vendu au client. Juste avant votre prochaine réunion d’avancement avec le client, votre commercial vous demande de ne mentionner au client ni le retard ni le fait que produit est encore en cours

de développement, car il prépare un appel d’offre lié à votre projet, et qu’un mauvais rapport sur ce projet peut avoir un impact négatif. Vous devez prendre cette décision très rapidement. Que faites-vous ? Décidez-vous de suivre les instructions du commercial et de vous taire, tout en sachant que vous être responsable de ce projet ? Ditesvous la vérité au client, au risque de fâcher votre commercial et de faire capoter l’appel d’offre ? Vous faut-il du temps pour réfléchir à la bonne décision ou allez vous faire intervenir une tierce personne comme les stakeholders ou la steering

committee ? Peut-être allez-vous passer outre ce commercial et interroger son supérieur quant à sa façon de faire, que vous n’appréciez pas ? Dans votre plan de management, vous avez dû définir une gouvernance du projet. Cela devrait vous donner la bonne réponse à apporter à la demande du commercial. Lorsqu’un problème tel que celui présenté dans l’exemple ci-dessus - se présente, le Manager de Projet doit avoir le courage de prendre des décisions difficiles comme d’envoyer balader un commercial ou de virer du projet un membre de l’équipe pour

incompétence ou manque de respect du code de déontologie. Il doit également savoir arrêter un projet s’il se rend compte qu’il n’est plus dans l’intérêt de personne de le continuer. Dans l’intensité du projet, prendre des décisions qui semblent évidentes vu de l’extérieur n’est pas aussi simple qu’il n’y parait. De nombreuses personnes, bien qu’elles voient que leur projet tourne à perte, persistent dans leurs efforts, notamment par peur de ce que les gens pourraient en penser. Les faits et chiffres: la technique de l’arbre de décision peut, par exemple, être utilisée par le Manager

de Projet avant de prendre une décision : Utiliser un arbre de décision pour trancher Décision à prendre : faut-il tester ou non le système de freinage à l’usine avant de vendre une voiture au grand public ? Avant de prendre cette décision, le Manager de Projet a en sa possession les données ci-dessous : Faits et chiffres : Il y a 100.000 systèmes de freinage à tester Chaque test à l’usine coûte : 2000€

Si le test passe, l’assemblage final coûte 1000€ Si le test échoue, la réparation du système de freinage et son assemblage coûtent 1500€ Si le test n’est pas effectué à l’usine et que la voiture rencontre un problème avec le système de freinage dans les mains du grand public, le coût de rapatriement du véhicule et de sa réparation coûte 5000€ Les données historiques indiquent que : 90% des tests de freinage sont un succès ou ne rencontrent aucun problème avec le grand public

10% des tests de freinage sont un échec ou rencontrent un problème une fois dans les mains du grand public. Arbre de décision: Sur la base de ces faits et chiffres, on peut obtenir l’arbre de décision ci-dessous qui permet d’évaluer l’interdépendance des risques :

À la lumière de ce diagramme, nous pouvons lire : Coût total si on fait les tests en usine : 30,5M€ Coût total si on ne fait pas les tests en usine : 20M€

Décision: L’arbre de décision n’impose pas de faire des tests au préalable avant de mettre la voiture en vente. Exemple 103: Arbre de décision

Le pile ou face: en lançant une pièce en l’air et en misant sur l’une des faces. Cela peut prêter à plaisanterie mais si l’on y réfléchit bien, nous avons tous vu ou connu des personnes jouer et prendre des risques en lançant une pièce de monnaie. En conclusion, un Manager de Projet doit être un meneur apte à prendre rapidement des décisions, sans être

paralysé par le poids de cette charge. Il doit être capable d’assumer ses décisions ainsi que les risques inhérents à celles-ci. Il ne doit pas fuir ses responsabilités ou laisser d’autres choisir à sa place. Quitte à se faire virer, autant que cela soit pour ses propres idées, plutôt que à cause de celles d’un autre. Et surtout, il ne faut pas oublier que voir ses choix récompensés par un succès est l’aspect le plus gratifiant dans le management de projet.

Une bonne communication et un sens aigu de la relation humaine « La grandeur d’un métier est avant

tout d’unir les hommes ; Il n’est qu’un luxe véritable et c’est celui des relations humaines » Antoine de Saint-Exupéry

Pourquoi une bonne communication est-elle importante? On dit que le management de projet est une science et un art. C’est la science de gérer des processus et c’est l’art d’établir de bonnes relations avec les gens, avec l’équipe chargée du projet, les parties prenantes, les fournisseurs et surtout le client. Lorsque l’on est Manager de Projet, on est amené à diriger des personnes et à

leur demander d’accomplir des tâches pour le compte du projet sans pour autant être leur supérieur hiérarchique. Il faut en effet interagir avec beaucoup d’interlocuteurs. Par exemple on demandera à l’équipe projet de faire les activités, aux stakeholders de tenir leurs engagements, aux personnes chargées des aspects financiers de s’occuper des facturations et des paiements, à l’équipe logistique d’assembler et de livrer les équipements et d’en faire un suivi, à l’équipe de support technique de venir en aide au projet, etc. En outre, le Manager de Projet doit aussi assurer une bonne communication avec le client et obtenir sa satisfaction.

Il est donc nécessaire pour un Manager de Projet d’avoir un sens aigu des relations humaines ainsi qu’une bonne communication afin d’obtenir de chaque personne ce qu’il attend d’elle, tout en veillant à n’offenser personne et en agissant avec tact et, si possible, gentillesse. Il est primordial de noter que la manière dont on communique un message est aussi importante que le message luimême : un Manager de Projet doit avoir de la substance et du style - de la substance dans le message, du style pour faire passer ce message. Il ne faut pas attendre des personnes avec qui l’on travaille qu’elles soient

toujours accueillantes et d’excellente humeur : la nature humaine a bon nombre de limitations et de dysfonctionnements. Il y a des moments ou certaines personnes adoptent un comportement désagréable ou difficile qu’il ne faut pas forcément lier à la charge de travail ou à la demande qui a été formulée, parfois de manière pressante, par le manager. Il peut arriver que ces humeurs soient dues à un manque de sommeil, à des difficultés personnelles ou à d’autres ennuis temporaires. Et comme le projet doit avancer malgré tout, le Manager de Projet doit interagir et composer intelligemment avec l’humeur et le comportement de ces personnes. Pour

autant, il faut que ces attitudes restent passagères ou sporadiques, car de tels comportements peuvent devenir problématiques pour le Manager de Projet s’ils deviennent habituels ou permanents. Par exemple, lorsqu’un client se met à penser qu’en se montrant désagréable il pourra mettre le Manager de Projet en position de faiblesse pour obtenir tout ce qu’il veut de lui.

Les super-sympas, les je-saistout, les frimeurs et grincheux etc Voici différents types de personnalités auxquels le Manager de Projet peut être confronté et avec lesquels il doit

pouvoir interagir: Les « super-sympas » : ceux qui vont toujours accueillir le Manager de Projet les bras ouverts, avec le sourire et un enthousiasme communicatif. C’est un cadeau et un plaisir de travailler avec eux ; Les « je-sais-tout » : ceux qui pensent avoir une connaissance supérieure, qui se montrent condescendants et arrogants, et qui se demandent toujours quel est, au fait, le rôle du manager ? ; Les « frimeurs » : ceux qui attendent respect et admiration de la part des autres pour des compétences qu’ils prétendent posséder alors qu’il

n’en est rien ; Les « grincheux » : ceux qui trouvent toujours quelque chose à dire et qui attendent du Manager de Projet qu’il fasse quelque chose pour eux ; Les « négatifs » : ceux qui disent toujours que tout va mal se passer si l’on ne suit pas leurs opinions et qui répètent ensuite sans cesse « je l’avais pourtant dit mais personne ne m’a écouté » ; Les « agressifs » : ceux qui ont des comportements hostiles et qui aiment malmener, et intimider les autres, en particulier ceux qu’ils trouvent faibles.

« La diplomatie est l’art d’amener les gens à faire les choses à votre manière. » Anonyme Le Manager de Projet peut être en difficulté pour obtenir quoique ce soit de ces personnes s’il se laisse dominer et ne sait pas demeurer sur un même pied d’égalité avec eux tout en leur faisant face. Il lui faut avoir un sens aigu des relations humaines et un bon sens de la communication, ce qui passe par un respect et une gentillesse mutuels. Il est cependant important de rappeler qu’il faut savoir être ferme voire dur face aux faits - notamment lorsque le projet à livrer prend du retard ou que sa qualité

laisse à désirer -, mais que cela ne doit pas empêcher de traiter avec humanité les personnes responsables de ces manquements. La qualité de la communication est un facteur de cohésion décisif dans une équipe projet. Elle est la base de toute relation intersubjonctive.

Figure 60: Manager de Projet en interaction avec des stakeholders ayant chacun son humeur

Qu’est ce qu’une bonne communication ? « Quand on sait entendre, on parle toujours bien. » Molière Bien communiquer ne signifie pas qu’il faut être extraverti, grand orateur, maître de la joute verbale ou encore tribun sachant parler avec beaucoup d’éloquence et de démagogie. Il faut simplement avoir du tact et de la diplomatie pour demander à son équipe d’exécuter des tâches bien définies. Une

communication

efficace

passe

également par l’écrit, notamment lors de la rédaction des e-mails. Il ne suffit pas de signer « Cordialement » : il faut veiller à ce que les directives soient énoncées de manière claire, sans heurter son interlocuteur par des formulations trop directives. En bref, bien communiquer consiste à rendre agréables, harmonieux et constructifs les rapports que l’on entretient avec ses interlocuteurs.

Figure 61: Manager de Projet avec un sens de l'écoute est un bon communicateur

Voici quelques comportements indispensables que doit maîtriser le Manager de Projet pour bien communiquer : S’informer : le Manager de Projet doit savoir s'informer auprès de tous les interlocuteurs quant aux rouages de l’organisation et du client. Il doit savoir où et comment trouver les informations utiles pour la réalisation de son projet. Écouter : savoir écouter quelqu’un est le plus flatteur des compliments

que l’on puisse lui faire. Les personnes qui communiquent le mieux sont toujours celles qui savent le mieux écouter et non pas nécessairement celles qui s’expriment le mieux. Un bon Manager de Projet doit savoir quand il faut se taire et quand il faut prendre la parole. Celui qui ne pense qu’à parler sans jamais écouter l’autre n’est pas un bon communicateur. Le manager doit être ouvert au dialogue et posséder une maturité émotionnelle qui lui permettra de tout entendre, notamment les critiques. Il doit également posséder un bon esprit de synthèse pour pouvoir

prendre du recul par rapport à ce qu’il aura entendu. Il doit avoir un sens aigu de l’écoute, en montrant de l’intérêt et de la sollicitude face à son interlocuteur et en l’encourageant à parler davantage. Il ne peut se contenter de l’écouter d’une oreille, en ayant la tête ailleurs, comme s’il écoutait de la musique de fond : premièrement, c’est un vrai manque de respect et, deuxièmement, s’il n’écoute pas activement ce que son interlocuteur a à dire, il ne pourra pas ensuite agir en conséquence. En outre, le Manager de Projet doit savoir maîtriser les clés de l’écoute active : donner des feedbacks ou

reformuler les propos de son interlocuteur. Ces feedbacks et reformulations sont très importants pour s’assurer que l’on a bien compris le message que l’autre souhaitait faire passer. Il est impératif d’apprendre à répéter ce que l’on vient d’entendre pour s’assurer que l’on a intégré correctement le message donné. S'exprimer: le Manager de Projet doit posséder une aisance à l'oral comme à l'écrit. Son discours doit être cohérent, logique et argumenté ; il doit savoir raisonner et être rigoureux. Il doit être capable de

s’exprimer simplement et sans sophistication inutile. Les problèmes et messages simples deviennent incompréhensibles dès lors qu’ils sont traités avec tout un vocabulaire faussement savant. Un Manager de Projet a besoin d’une communication continue et claire pour s’exprimer. C’est aussi savoir exprimer sa gratitude et sa fierté en félicitant avec des mots simples son équipe quand celle-ci a été efficace et performante. Ne dit pas-t-on que l’éloge sincère, sans flagornerie est le miel de toute relation ? Et, dans toute communication, le sourire comme l’humour n’est pas synonyme de

manque de professionnalisme et de sérieux : au contraire, le sourire donne de l’énergie aux gens et le Manager de Projet ne doit pas s’en priver en s’exprimant. « Quand les gens parlent, écoutez-les totalement. La plupart des gens n’écoutent jamais » Ernest Hemingway Communiquer : sur un projet, il n’y a rien de plus terrible ou de pire qu’un Manager de Projet qui ne communique pas ou qui communique mal avec son équipe et avec les stakeholders. Le Manager de Projet doit être constamment connecté avec

les autres et savoir établir des relations entre les personnes. Un plan de management de la communication doit être clairement défini et établi lorsque l’on démarre un projet. En effet, le plus motivant pour les membres de l’équipe et surtout pour les stakeholders, c’est d’avoir le sentiment qu’ils ne sont pas traités à la légère, qu’il sont inclus, et qu’ils participent réellement au projet. Pour cela, il faut qu’ils soient informés et considérés avec respect. Il faut une communication saine et ouverte, surtout lorsqu’il s’agit de mauvaises nouvelles. Lorsque cela n’est pas le cas, certains peuvent devenir inquiets

voire paranoïaques, car ces personnes pensent immédiatement au pire lorsqu’ils ne sont pas informés…De plus, quand toute une équipe se sent en insécurité, son moral est touché et cela crée avec le temps une atmosphère négative, les relations deviennent pauvres et il peut y avoir des breakdown émotionnels. Il faut donc de la présence en communication de résolution de problèmes et en communication de support et d’appui. Une communication mauvaise, insuffisante ou tout simplement absente peut amener toute une équipe

à l’insurrection. Pensons à l’exemple de ces joueurs de football qui ont décidé de faire grève en pleine Coupe du monde de football, parce que leur coach ne leur parlait pas assez… Métacommuniquer : Méta signifie en grec « au-delà de », ce qui englobe et donne du sens. Le Manager de Projet doit être capable de sortir du contenu de son message pour observer ce qui se passe dans la relation, avec chaque interlocuteur. Métacommuniquer, c’est échanger sur sa propre communication au niveau du contenu ou de la relation. Par

exemple, en tapant sur un verre pour obtenir le silence, le Manager de Projet « métacommunique » son souhait de communiquer quelque chose. Ne pas métacommuniquer, ne pas prendre de recul, peut mener au risque de voir la communication s’enfermer dans le conflit. Il faut savoir dire, quand il le faut, « quelque chose ne va pas ». Lorsque l’on tape une mauvaise commande sur son ordinateur, celui-ci réagit en envoyant un message d’erreur ou en faisant un bruit inhabituel qui nous alerte. On devrait être capable de détecter ces bruits « bizarres » dans nos communications. On peut être

frustré, taper avec force sur le clavier, ou le jeter contre le mur, mais cela n’aide en rien l’ordinateur. De même dans la communication entre personnes, dès que l’on a tendance à sortir de nos gonds, un message d’erreur devrait s’afficher dans notre cerveau pour nous dire de nous corriger et de prendre le temps de comprendre ce que l’autre veut, tout simplement.

Conquérir : le Manager de Projet

doit savoir encourager les dialogues et conquérir la sympathie d’une personne pour la mettre d’une humeur favorable et finalement la rallier à la cause que l’on souhaite voir défendue. Quand une personne adhère à une cause – dans ce cas-ci, le projet - elle peut démultiplier ses efforts. Mais pour conquérir ces personnes, le manager doit faire preuve de compréhension de l’autre et agir en fonction de cela. Comprendre sans agir, sans tenir compte de ce que l’autre vient de dire ou de faire n’est pas signe d’une bonne communication. Il faut être capable de faire preuve de plus

d’attention humaine dans sa communication, sans prendre les gens de haut. Un Manager de Projet ne doit ni juger, ni dénigrer ni colporter des ragots sur son management, son équipe, sur les stakeholders, ni sur quiconque d’ailleurs. Quand on en arrive à de telles attitudes, c’est un signe de découragement. Cela donne l’image d’une personne qui a décroché et qui a perdu et on ne peut pas rassembler des personnes autour d’une cause quand on est découragé et défait.

Communication non violente (CNV) Tout Manager de Projet désireux de

communiquer avec plus d’authenticité et d’efficacité devrait s’initier à la communication non-violente telle que modelée par Marshall B. Rosenberg. Il arrive qu’un Manager de Projet ressente de la frustration, de la colère, de l’incompréhension envers les membres de son équipe, les stakeholders, et surtout vis-à-vis du client. Il peut en arriver à avoir envie d’agir de manière « violente » et de se comporter de manière blessante, sans tact ni gentillesse, que cela soit volontaire ou non. Quand la tentation est forte de briser la règle d’or - qui veut que l’on n’animalise, « zoologise » ou « physiologise » jamais ses adversaires

-, le Manager de Projet devrait se tourner vers ce modèle de communication qui peut lui être bénéfique pour transmettre l’empathie, la coopération harmonieuse et le respect des autres et de soi.

Figure 62: Modèle de communication non-

violente

Ce modèle de communication se résume en un cheminement en quatre temps : 1. Observation objective de la situation en mettant de côté jugements et évaluations. Par exemple, Daniel, le Manager de Projet trouve la performance de Philippe, un membre de l’équipe projet, mauvaise. Et de son côté, Philippe est démotivé et se plaint que Daniel ne l’écoute pas assez, ne développe pas ses compétences et ne prend jamais en compte son avis. 2. Identification des sentiments qu’éveille la

situation en les différenciant de nos interprétations et de nos jugements. Par exemple, Daniel peut sentir de la colère, de la frustration par rapport à la situation où Philippe n’apporte aucune valeur ajoutée. Philippe de son côté traine sa mélancolie et se sent triste, rejeté et pas intégré dans l’équipe et il se sent vraiment seul. 3. Identification des besoins liés à ces sentiments. Par exemple, Daniel a besoin que Philippe travaille et se donne un peu plus pour l’équipe. De son côté, Philippe a de profondes aspirations de se développer afin de monter en compétence sur les tâches que

Daniel lui demande d’effectuer. 4. Formulation d’une demande en vue de satisfaire ces besoins. Par exemple, Daniel peut demander à Philippe de s’investir un peu plus, de ne pas hésiter à demander de l’aide aux autres membres de l’équipe. De son côté, Philippe peut demander qu’on l’envoie en formation afin de pouvoir s’investir un peu plus. Enfin, savoir communiquer, c’est aussi avoir une panoplie de compétences en réserve pour résoudre les problèmes, car la plupart des échanges du Manager de Projet ne traite que de ça. Le Manager de Projet peut s’appuyer sur

cet outil de communication non-violente en quatre étapes, en respectant l’ordre, pour la résolution de conflits entre les membres de son équipe, ou avec les stakeholders.

Possession d’une maturité émotionnelle « Ce ne sont ni les chiffres ni les courbes qui font bouger les choses mais les émotions. » Michel Serres La maturité émotionnelle aide à découvrir notre seuil de tolérance de manière à prévenir les conflits relationnels avec le client, les

stakeholders et les membres de l’équipe projet. Elle permet également au Manager de Projet d’avoir du recul et de ne pas se laisser ronger par la pression et le stress engendrés sur le projet, qui peuvent parfois entraîner une dégradation de son état de santé physique et mental. Un projet, tout comme la vie, n'est pas toujours fait que de bons moments, des événements moins joyeux en font aussi partie . J’ai été personnellement témoin de situations dans lesquelles des managers de projet craquaient face à la pression de plus en plus intense et aux stress générés par les attentes de plus en plus grandes des stakeholders (crises

de larmes et de nerfs qui éclatent spontanément, etc.). Nous avons tous nos limites émotionnelles et la goutte qui fait déborder le vase tient parfois à peu de choses, comme une facture en retard, un livrable mal rendu, la remarque désobligeante d’un stakeholder, etc. Le Manager de Projet doit pouvoir faire preuve de maturité émotionnelle pour maîtriser ses émotions à tout moment, pas uniquement lors de situations qui sont très dures à vivre émotionnellement. Il doit pouvoir percevoir, évaluer, contrôler et diriger ses émotions par rapport aux actions de tous les acteurs du projet.

Les moments éprouvants

émotionnellement sur un projet Le Manager de Projet doit pouvoir faire preuve de maturité émotionnelle particulièrement face aux situations éprouvantes suivantes : Les accueils et paroles hostiles : le Manager de Projet n’est pas toujours accueilli avec le sourire par le client, les membres de sa propre équipe ou les stakeholders. Lorsque leur niveau de satisfaction est au plus bas et leur exaspération élevée, par exemple lorsqu’ils ont l’impression que le Manager de Projet ne répond pas à leurs attentes, dans ces moments de grande tension très palpable, ces derniers ne vont pas se

gêner pour élever la voix, crier leur mécontentement et proférer même des paroles très dures, parfois excessives, à l’encontre du manager du projet et de sa performance. Face à ces relations tendues avec le client et autres stakeholders, la maturité émotionnelle du Manager de Projet devrait le pousser à ne pas vociférer en retour, même si la tentation est grande, et à garder son calme. Il faut pouvoir tout simplement acquiescer, leur déclarer que l’on comprend leur colère avant d’enchaîner sur les faits qui ont abouti à ces émotions et de proposer par la suite un plan d’action correctif.

« Les paroles les plus destructrices ne sont pas celles que l'on vous dit, mais plutôt celles que vous dites à vous-même. » Zig Ziglar Les mauvaises nouvelles : l'annonce d'une mauvaise nouvelle est toujours un moment délicat, on sait qu’elle provoquera un choc et sans doute la colère du client, du stakeholder ou d’un membre de son équipe. Le Manager de Projet doit faire preuve de bravoure en annonçant les mauvaises nouvelles le plus tôt possible et en toute transparence. Lorsque, par exemple,

le produit livré n’est pas fini et est rempli de bugs ou encore, lorsque le projet n’a pas tenu ses promesses et n’est plus en mesure de livrer les attentes du client, le Manager de Projet ne devrait pas cacher la situation sous prétexte que cela mettra le client hors de lui, car cela peut avoir un impact conséquent sur le contrat du projet ou encore sur son plan de carrière. Il faut pouvoir annoncer les mauvaises nouvelles en faisant preuve de tact et de recul, en proposant immédiatement d’améliorer les choses par l’élaboration d’un solide plan d’actions. Le Manager de Projet doit

faire preuve de compréhension, d’empathie, de présence et de maturité émotionnelle pour maîtriser ses émotions en adoptant une mine de conséquence, en s’exprimant clairement de façon à se faire entendre sans verser dans l’ironie et la froideur. Les critiques destructives à l’endroit du Manager de Projet : le Manager de Projet est dans l’action, et toute personne se trouvant dans l’action est susceptible d’être critiqué. Au cours du projet, il est certain que le Manager de Projet devra faire face à des situations où

ses actions et ses idées seront confrontées et questionnées, voire durement critiquées. L’arme de démotivation massive qu’est la critique destructive, même à petite dose, peut provoquer une blessure émotive, peut engendrer du stress et de la pression inutile en même temps que procurer un sentiment d'incompétence et par conséquent, une baisse de rendement, voire un burn-out. Le Manager de Projet qui travaille dur apprécie de recevoir des compliments ou des commentaires positifs sur le travail accompli. Mais il doit pouvoir être à même d’accepter émotionnellement

les critiques de toutes sortes, sans pour autant les percevoir comme un échec ni les laisser affecter sérieusement son humeur dans ses tâches professionnelles ou l’envahir dans sa vie personnelle. Il doit pouvoir régler les conflits et préserver l’harmonie dans le contact avec les autres, ainsi qu’accepter que chacun ait sa propre vision d'une situation donnée. La critique permet une remise en question et une analyse de la situation débouchant, par la suite, sur un plan d’actions correctif pour réparer les dégâts et un plan d’actions préventif pour les empêcher de se reproduire à

nouveau. Le rejet des membres de l’équipe et des stakeholders : déléguer les activités du projet, ou encore, demander aux stakeholders de s’engager davantage sur le projet fait partie des prérogatives du Manager de Projet. Cependant il est inévitable que par moments, certains stakeholders difficiles ou membres de sa propre équipe projet, ignoreront ces demandes et iront même jusqu’à remettre en cause la façon de faire, la vision et les décisions du Manager de Projet, jugeant ses décisions inutiles et

inefficaces. Ce rejet peut être émotionnellement très pénible pour le Manager de Projet, affectant son estime de soi et l’évaluation de ses compétences. De petits détails comme un malentendu peuvent être à l’origine de dysfonctionnements, comme dans le cas d’un Manager de Projet débarquant sur le projet et désirant agir rapidement pour montrer son efficacité et fonctionner avec ses propres repères sans tenir compte des facteurs environnementaux. Lorsqu’on vient d’arriver sur le projet, rien ne sert de se précipiter, il faut accepter au début de se faire « manager par

l’environnement », d’abandonner certaines certitudes et de s’adapter à l’évolution de la situation. La manière d’interpréter émotionnellement le rejet est importante. Certains ont tendance à jeter l’éponge et s’arrêter net, d’autres se lamentent en pensant qu’ils sont bien seuls au monde et d’autres encore ont la maturité émotionnelle pour s’affirmer et maîtriser leurs émotions. La clé n’est pas vraiment de trouver des excuses mais des solutions comme, par exemple, une redéfinition de la matrice des rôles et des responsabilités de chacun sur le

projet, en demandant que tout le monde la comprenne et l’applique. Sentiment d’isolement : les organisations deviennent de plus en plus virtuelles, les réunions se font de plus en plus à distance via ordinateurs et téléphones portables et le Manager de Projet est amené à travailler avec un client, des stakeholders et membres de l’équipe projet du bout du monde à des milliers de kilomètres les uns des autres. Le contact humain se fait rare et un sentiment d’isolement peut se développer car le Manager de Projet, avant tout animal social, se retrouve

coupé de la vie d’entreprise, de la pause café avec ses collègues, des open-spacesbruyants. Il peut alors éprouver une désaffiliation caractérisée par des difficultés à établir une relation de subordination avec les membres de l’équipe, en plus de la dissolution du sens de la mission collective, l’impression de porter tout seul sur ses épaules le poids, la pression de livrer le projet. Or, un des facteurs d’échecs d’un projet est le manque de support de l’organisation au Manager de Projet. Le sentiment d'appartenance à un groupe de ces managers de projet « virtuels » sera lié au vécu

professionnel collectif avec les stakeholders, les membres de l’équipe et le client, à savoir la vie et les événements vécus sur le projet. Dans ces moments éprouvants émotionnellement, le Manager de Projet doit pouvoir faire preuve d’empathie avec d’une aptitude à s’effacer momentanément pour comprendre les raisons derrière les émotions manifestées par le client, le stakeholder ou le membre de l’équipe projet. Le Manager de Projet ne doit surtout pas se perdre en excuses ou, pire, chercher à blâmer les autres mais, au contraire, il doit pouvoir être à l’écoute et proposer un plan d’actions correctives et

préventives dans les moments difficiles.

Être mature émotionnellement Etre mature émotionnellement implique que le Manager de Projet doive disposer du « savoir-faire » et « savoir-faire faire » nécessaires pour ne pas tomber dans les 5 Péchés capitaux du Manager de Projet.

Les 5 Péchés capitaux du Manager d On les rencontre dans tout projet, ils projet. 1. Ambition démesurée : avid défini auparavant dans le scope ou étapes nécessaires de validation, renommée, la fortune ou le pouvoir 2. Arrogance : hybris, fierté ou pré passer pour une personne supérie

que tout le mond manager le pousse par peur ou par h incapable inutile et doit pouvoir co prorogatives et ses capacités à le demander de l’aide ou escalader ses scopes. 3. Ignorance : le fait de n’être au cou n’être informé ni des objectifs du problèmes en cours sur les projets, projet. Ces managers de projets cu substance. Ce sont souvent des est leur propre projet qui se laissent un autres. 4. Abstinence : le fait de vouloir se dans les décisions par lâcheté ou de responsabilité. Ces managers s contribuer au projet, refusent

répondent jamais aux e-mails et a 5. Tricherie : le fait de se mettre im commençant un jeu de faux-sem de mentir, de tromper dans le but ses lacunes, de prendre l’avantage ou encore d’éviter des confronta émotionnellement n’osent pas la projet n’ont pas le sens de l’éthiqu Loi 6 : Les 5 Péchés capitaux du Manager de Projet (Source: Chaos Manifesto 2009 du Standish Group)

Enfin, sans être exhaustif, on peut dire qu’un Manager de Projet mature émotionnellement doit pouvoir : évaluer avant de juger ; avoir la capacité et la volonté d’assumer totalement la

responsabilité de ce qu’il dit ou fait ; devenir conscient des choix qu’il fait et de l'impact de ces choix ; comprendre comment il se limite inutilement et comment il peut, par choix, affronter et mettre fin à ces limites ; être attentif à toute la gamme possible des émotions, puisqu’elles permettent la communication en fournissant les bases de la différenciation et le discernement de son impact ; prendre sur lui les rejets, les colères, ravaler sa fierté et reconnaître ses erreurs ; faire preuve de capacité de

réaction en sachant transformer le cours du projet en fonction de nouveaux éléments qui se produisent ; en se montrant chercheur de solutions ; en pensant positivement et sachant prendre sur lui afin d'éviter de communiquer une quelconque anxiété à son équipe.

La force de la maturité émotionnelle Étymologiquement, l’émotion est ce qui met en mouvement, ce qui fait avancer et agir. La maturité émotionnelle d’une personne est souvent prédictive de sa réussite car il semblerait qu’on ne dirige pas efficacement sans communication de son émotion et de son désir (ou de sa

peur). De plus, l’émotion est le principal moteur de nos actions et de ce qui nous rend humain, et toute connaissance qui n’a pas été précédée par une sensation ou une émotion est inutile. La maîtrise et la conscience des émotions, les siennes et celles de son client, de son équipe projet ou encore des stakeholders, sont donc essentielles car elles affinent notre appréciation d’une situation et précisent notre capacité à décider et à agir. C’est cette maturité émotionnelle qui lie le Manager de Projet avec son équipe et les stakeholders sur un projet, et cette relation est encore plus forte durant les moments particulièrement difficiles. Quand les gens sont soumis à une forte

pression et à un stress intense, ils ont d’habitude,l’instinct de s’auto-préserver, de quitter le navire et d’abandonner les autres pour ne penser qu’à leur carrière, mais cette maturité qui soude l’équipe va faire primer l’envie de réussir ensemble sur son intérêt personnel. Le Manager de Projet est responsable de l’issue du projet et doit être, comme un pilote, le dernier à sortir de l’avion lorsque celui-ci est arrivé à bonne destination et que tous les passagers sont débarqués, quelle que soit la façon dont le vol s’est déroulé. Un Manager de Projet, émotionnellement mature, maîtrise également:

Le timing : le Manager de Projet doit savoir quand il faut laisser tomber certaines choses, quand s’arrêter dans les joutes verbales par exemple, quand il faut prendre du recul pour mieux avancer, quand il faut ouvrir son parachute, quand il faut lâcher prise, reconnaître une fatigue mentale et émotionnelle entraînant une baisse de motivation et passer la main, etc. L’impartialité : sous l’effet de l’émotion, il faut éviter de perdre son sang-froid car la tentation de s’emporter est grande par moment. Sous le coup de l’émotion, le

Manager de Projet mature évite de faire du favoritisme envers un stakeholder, il respecte les faits, le scope et le plan de management. Enfin, dévoiler ses sentiments et ses émotions n’est pas un signe de faiblesse, même si l’on préférerait se montrer fort, maître de soi, invincible, se hisser audessus de sa nature humaine pour paraître performant. Plutôt que de s’acharner à avoir l’air de ce qu’on n’est pas, il est bien plus simple et sain de vivre ce que l’on est et d’exprimer ce que l’on ressent. C’est aussi se montrer professionnel que d’avouer ses erreurs, de demander de l’aide. Les managers de projet émotionnellement matures maîtrisent l'art de vivre de façon

détendue dans un monde où le « time-tomarket » des projets est devenu de plus en plus court et génère de ce fait une pression très forte et un stress intense.

Compétences managériales Pour un Manager de Projet, la moitié de la bataille dans les tranchées du management du projet est l’enjeu collectif fort qui consiste à faire travailler ensemble et de manière efficace des experts multitâches mis à sa disposition pour réaliser le projet et cela dans un climat de coopération, favorisant les attitudes positives et faisant appel aux compétences managériales. Ces dernières n’impliquent pas d’acquérir un certain

niveau de sophistication en se montrant plus intelligent que tout membre de son équipe projet. Il s’agit plutôt de pouvoir adopter des comportements adéquats par rapport à son équipe, aussi bien en ce qui concerne les tâches à lui faire effectuer que le domaine relationnel. Cela s’avère plus facile quand le Manager de Projet peut composer sa dream team en choisissant lui-même son équipe mais, la plupart du temps, celleci lui est imposée par l’organisation en fonction des disponibilités des ressources. En tous les cas, quel que soit le membre de l’équipe, choisi ou pas par le Manager de Projet, interne ou externe à l’organisation, le Manager de Projet

doit pouvoir révéler la cohérence et la complémentarité de son équipe et la manager de façon à ce qu’elle démontre rapidement un sens de l’engagement orienté vers la performance. Un Manager de Projet qui parvient à tirer le meilleur parti de ses ressources, possède à sa disposition une équipe de high performers qui sauront faire face ensemble à toutes difficultés et défis que présentera le projet.

La cohésion de l’équipe avant toute chose « J’ai horreur de ceux dont les paroles vont plus loin que les actes. » Albert Camus

Faire preuve de compétence managériale, c’est savoir placer son équipe projet dans les conditions les plus favorables possibles pour effectuer ses tâches. Il ne s’agit plus de soi mais de faire passer son équipe avant soi, de comprendre que son succès dépend avant tout de celui de l’équipe. Altruiste, le Manager de Projet doit nourrir le désir de se rendre utile à son équipe et de répondre présent dès qu’elle a besoin d’écoute, de soutien, d’outils, de conseils, etc. Il doit pouvoir se surpasser pour l’équipe projet, obtenir pour elle les meilleurs équipements et outils pour que ses membres puissent effectuer leurs tâches correctement.

Faire preuve de compétence managériale, c’est aussi laisser du champ libre à son équipe projet pour qu’elle puisse se prendre en charge et que chaque membre exécute ses tâches avec sa créativité propre. C’est aussi faire montre d’esprit d’équipe, savoir valoriser les participations de chacun dans leurs tâches respectives : le membre de l’équipe qui sent que son travail est bien valorisé a tendance à s’investir et à participer davantage.

Coordonner et diriger avec autorité et charme « Le charme : une manière de s'entendre répondre "oui" sans avoir posé aucune question claire. » Albert Camus Faire preuve de compétence managériale, c’est également être à même d’élaborer un plan et d’agir en exécutant et en contrôlant ce plan. Le Manager de Projet doit pouvoir coordonner et diriger son équipe pour effectuer le travail en donnant des

orientations claires touten faisant montre d’autorité. Il doit donc pouvoir déléguer en confiant des objectifs SMART et il doit connaître les indicateurs de réussite pour les atteindre. Savoir déléguer sans tomber dans le micro-management, en sachant limiter ses prérogatives et en définissant clairement les processus que chacun des membres de l’équipe doit appliquer. Les équipes performantes reposent sur l’application de processus explicites, partagés, où les rôles des uns et des autres sont identifiés et actés. Le Manager de Projet doit pouvoir faire confiance à l’équipe en l’encourageant, en l’épaulant et en la laissant faire preuve d’initiative, sans négliger les

idées nouvelles et les pistes créatives.

Figure 63: Manager de Projet qui élabore, exécute et contrôle son plan de jeu

Enfin, faire preuve de compétence managériale, c’est aussi pouvoir critiquer et évaluer les résultats obtenus sous la forme d’un bilan, tout en sachant récompenser à bon escient l’effort et la performance. Le Manager de Projetdoit pouvoir encourager son équipe à l’avance et la féliciter. Ne pas s’approprier les honneurs ou rejeter la faute sur son équipe car le mérite revient avant tout à ses membres qui se sont investis dans le projet .

Un environnement coopératif

agréable et un climat de confiance Faire preuve de compétence managériale, c’est pouvoir créer une bonne ambiance dans l’équipe projet en suscitant sa loyauté et un environnement qui encourage le progrès et qui réduit le stress. Ce n’est pas facile mais c’est vraiment essentiel, car l’impact d’une atmosphère négative est très néfaste pour le projet. Souvenons-nous du psychodrame de l’équipe de France de foot en Afrique du Sud, l’équipe ayant fait grève pour protester contre les décisions de son management. Dans son blog sur Sport24, Bruno Roger-Petit décrit les faits comme suit : « le

sélectionneur de l'équipe de France en est réduit à être injurié par le joueur qu'il a lui-même protégé, propulsé, imposé en dépit de tout bon sens, persistant à lui donner chance après chance dans l'espoir que cela marche. Et la récompense de cette démarche suicidaire lui est revenue comme un boomerang sous la forme la plus basse et la plus immonde : l'injure. » Le fautif est-il le joueur ou son manager qui n’a pas suffisamment de compétence managériale pour créer un climat sain et un environnement propice au projet de l’équipe, qui était de devenir championne du monde de football ? Pour créer un climat de confiance,

facteur déterminant de la performance collective, le Manager de Projet doit pouvoir respecter les différences de chacun des membres qui composent l’équipe projet, pouvoir adapter son style à la sensibilité de chacun, ne pas toujours essayer d’avoir le dernier mot, comprendre le rôle de chacun, s’assurer que chacun sache ce qu’on attend de lui, le former à apporter des solutions et non pas à créer des problèmes. Faire preuve de compétence managériale, c’est aussi pouvoir manager les crises au sein de l’équipe afin de garder un climat sain. Il ne faut surtout pas s’énerver ni prendre les choses personnellement, mais garder son

sang-froid et faire preuve d’une certaine maturité émotionnelle. Comment ? En affrontant le plus tôt possible les faits.

Le dépassement par la performance collective Un “gold” Manager de Projet doit faire preuve de compétence managériale en développant et en maintenant une performance collective sur un projet où chacun des membres de l’équipe projet, y compris lui-même, se dépasse pour les autres dans l’intérêt du projet. Cette performance collective du groupe est supérieure à la somme des performances individuelles de chacun des membres de l’équipe projet, et elle se manifeste par les qualités suivantes :

le dépassement de soi : chaque membre de l’équipe projet, y compris le Manager de Projet, exploite son potentiel au maximum pour donner le meilleur de luimême ; le don de soi : chaque membre de l’équipe projet, y compris le Manager de Projet, accepte de coopérer avec des gens qu’il n'apprécie pas forcément pour le besoin de la collectivité. Faire preuve de compétence managériale, c’est pouvoir motiver son équipe projet. On sait que la motivation n’est pas une donnée qu’on peut déclencher à loisir. Il s’agit de favoriser

le don et le dépassement de soi au sein de l’équipe. Savoir motiver, c'est créer les conditions favorables pour que le projet réussisse. Par la consultation et la concertation, le Manager de Projet responsabilise son équipe et lui insuffle de la motivation. Faire preuve de compétence managériale, c’est aussi pouvoir développer la notion de partage entre les membres de l’équipe projet. L’envie de partager avec les autres favorise le don et le dépassement de soi. Le partage ne peut se faire que par le renforcement de la cohésion de l’équipe et l’amélioration des synergies relationnelles.

Enfin, pour améliorer la performance collective, le Manager de Projet doit être à même de sortir chacun des membres de l’équipe de projet de sa « zone de confort » (se réfugier derrière sa compétence et se complaire dans ce que l’on fait sans chercher à aller vers le domaine des compétences des autres). Pour ce faire, le Manager de Projet doit pouvoir encourager chacun des membres de l’équipe projet à faire don de soi et à se dépasser en sortant de son domaine de compétences pour le bien de la collectivité. J’ai rencontré un Manager de Projet qui n’a pas hésité à retrousser ses manches pour aider un expert à finaliser ses scripts et passer les tests

afin d’éviter que le projet prenne du retard. Sur un projet à l’équipe soudée, surtout pendant la phase d’accélération finale, on voit souvent des membres sortir de leur zone de confort pour donner un coup de main à leurs collègues.

Responsable, intègre et honnête « La politesse coûte peu et achète tout. » Montaigne Même si le travail du Manager de Projet est souvent stressant et que la pression peut être très forte, il ne doit jamais perdre de vue certaines valeurs essentielles. Il est tentant d’accepter des

cadeaux de fournisseurs ou des parties prenantes, pour ensuite les favoriser et il est facile de truquer les chiffres quant aux performances d’un projet… Mais à force de courir après la réussite à tout prix, on oublie rapidement l’essentiel. La fin ne justifie pas tous les moyens : il faut travailler sans se détourner des codes de l’éthique et en restant honnête, responsable, intègre et respectueux des autres. Le Manager de Projet doit donner de l’importance aux moyens qu’il engage car ceux-ci conditionneront le résultat final. Il est indispensable que, dès le début, le manager informe son équipe des valeurs,

attitudes et comportements qu’il attend d’eux tout au long de la réalisation du projet. Et il est primordial qu’il montre l’exemple dans ce domaine, qu’il insuffle un esprit d’équipe et de loyauté. Le Manager de Projet doit faire preuve de consistance : il doit dire ce qu'il fait et faire ce qu'il dit. Il doit respecter ses engagements et être une personne sur qui l’on peut compter. Cela semble évident pour les personnes de bon sens mais l’on croise encore occasionnellement des managers de projet malhonnêtes dans leur manière de travailler falsifiant les chiffres quant à la réalité du projet, par exemple -, qui ne sont pas intègres et qui se mentent à eux même

comme au reste de l’équipe. Or le manque d’honnêteté, d’intégrité et l’absence du sens des responsabilités tuent inévitablement la motivation et donc la productivité d’une équipe. Voilà pourquoi le fait de savoir forcer le respect et l’admiration sur le projet, non pas à coups de fusil à pompe, mais en montrant l’exemple d’un travailleur acharné avec des valeurs saines, est une stratégie gagnante. Par ailleurs, si le Manager de Projet doit être capable de transmettre à son équipe son souci d’intégrité et de respect des valeurs de l’entreprise, il doit également promouvoir le sentiment de fierté du devoir bien accompli qui accompagne

de telles responsabilités. Cela augmente également la chance de succès d’un projet.

Figure 64: Manager un projet comme un ange même contre les démons

Respect Le Manager de Projet doit faire preuve de respect envers les autres et ne pas se comporter de manière grossière et agressive, quelles que soient les circonstances et même lorsque les membres de l’équipe-projet, les stakeholders et surtout les clients, mènent un combat déloyal et sournois. Il faut absolument éviter de faire sienne la loi du talion : tout le monde a droit au respect et à une attitude civilisée. Mais respecter son équipe, les stakeholders ou les clients ne passe pas uniquement par un comportement

mesuré : il faut également honorer sa parole et ses engagements, ne pas dire du mal d’eux ou répandre des rumeurs dès qu’ils ont le dos tourné, faire preuve de tolérance et d’acceptation des différences dans les façons de faire ou de communiquer… C’est aussi avoir l’honnêteté et la franchise de parler à ses interlocuteurs sans user de langue de bois. On croise un grand nombre de managers incapables de parler franchement à leur équipe lorsque les choses se passent mal, bien qu’ils souhaitent voir la situation changer. Certains préfèrent mentir ou réparer seuls le mal fait plutôt que d’avoir le courage de mener une discussion avec la

personne concernée. Cela nuit non seulement au projet, mais également à la qualité de vie du manager qui voit encore augmenter ses heures de travail. La vie peut parfois sembler plus facile sans confrontation et être honnête est souvent pénible, mais il est impératif d’être franc pour le bien de l’équipe et du projet. Quand tout le monde sait ce que l’on attend de chacun, en toute transparence, il est alors possible de rencontrer une certaine fluidité dans la manière de travailler. Il ne faut surtout pas croire que pour être Manager de Projet il faut se montrer sophistiqué dans ses attitudes. Il faut, au contraire, savoir respecter les règles

basiques de politesse, de gentillesse et d’amabilité. Comme je l’ai déjà mentionné précédemment, le manager peut être sévère avec les faits, mais il se doit de rester agréable avec la personne responsable de ces faits.

Honnêteté Le Manager de Projetdoit être honnête et cultiver le souci de transparence. Il doit pouvoir dire sincèrement ce qu’il pense et ce qu’il souhaite, aussi douloureuse que soit la vérité. Cela est nécessaire pour réduire les barrières de communication et pour bâtir des relations de confiance durables qui faciliteront les prises de décisions. Le Manager de Projet ne doit surtout pas

succomber à la facilité en falsifiant les rapports sur le projet pour tenter de masquer son incompétence. Au contraire, il doit préférer aux mensonges une vérité claire, appuyée par les faits, sans avoir recours à des subterfuges pour qu’elle passe plus facilement. En cas de difficultés, il doit prendre son courage à deux mains et assumer ses responsabilités. Tout le monde connait l’adage selon lequel la forme serait plus importante que le fond. Pourtant, une forme sans fond ne vaudra jamais la consistance des seuls faits. Il est donc important que le Manager de Projet sache parler honnêtement, sans biaiser pour tenter de

garder la face ou d’éviter les confrontations. En effet, il n’y a rien de pire pour une équipe qu’un manager qui ne sait pas se montrer honnête et qui traite ses collaborateurs avec condescendance. Mais s’il se doit d’être franc, il doit également veiller à ne pas proférer de critiques non-constructives ou dictées par la rancune.

Intégrité « Il y a trois qualités essentielles qui sont l’intégrité, l’intelligence et l’énergie. Mais il ne faut pas oublier que si vous n’avez pas la première,

les deux autres vous tueront. » Warren Buffet Le Manager de Projet doit conserver une intégrité à toute épreuve. Il doit par conséquent éviter de faire de la rétention ou de l’omission délibérée d’informations dans le but de se couvrir, de couvrir d’autres ou encore de favoriser l’une ou l’autre personne. Un Manager de Projet intègre doit également veiller à éviter tout type de discrimination et tout comportement équivoque qui risqueraient de créer confusion et division au sein de son équipe. Nous sommes tous influencés dans nos jugement par nos vécus personnels,

organisationnels, sociétaux et culturels et nous réagissons tous différemment face à certaines situations. Mais il y a quelques points sur lesquels une seule ligne de conduite s’impose. Il n’est pas question d’accepter des fournisseurs des cadeaux d’un montant supérieur à celui autorisé par son organisation. Et si les cadeaux dont la valeur est inférieure à ce montant peuvent être acceptés, ils ne doivent en aucun cas influencer le jugement du Manager de Projet vis-à-vis du fournisseur qui lui a donné ce cadeau - en cas de négociations pour un renouvellement de contrat, par exemple. Le Manager de Projet doit veiller à éviter tout conflit d’intérêts. Rien ne

l’oblige à accepter un cadeau s’il a l’impression que le fournisseur essaye de le soudoyer.

Responsabilité Un Manager de Projet doit être capable d’assumer la responsabilité de ses décisions, de ses choix et de ses actes – qu’ils soient bons ou mauvais. Il doit être capable de laisser son équipe récolter les honneurs quand le projet est réussi et prendre à son compte les reproches quand le projet tourne moins bien. Un Manager de Projet ne doit pas agir de manière lâche en se déchargeant du poids de ses responsabilités pour échapper aux conséquences de ses actes ou en blâmant le reste de l’équipe

pour ses propres manquements. Il est bien sur beaucoup plus facile d’accuser la logistique qui n’a pas envoyé les équipements à temps, d’accuser l’architecte qui a mal dimensionné la solution, etc… Mais le Manager de Projetne devrait pas oublier qu’en fin de compte, il était de son ressort de mettre en place une structure et un cadre efficaces qui auraient exercé un contrôle sur les produits ou solutions à livrer, pour éviter toute erreur. Par ailleurs, un Manager de Projetresponsable doit être autonome quand il le faut et savoir demander de l’aide quand cela est nécessaire. Il doit également être capable de prendre des

initiatives sans attendre qu’on lui formule des instructions. Enfin, il doit savoir faire front face à tout obstacle qui se présente devant lui .

Un sens de l’éthique irréprochable Le Manager de Projet doit avoir un grand sens de la déontologie et de l’éthique. La déontologie est la conscience de ses devoirs et l’éthique est la science de la morale. Aujourd’hui, les praticiens du management de projet certifiés PMP® par Project Management Institute (PMI) s’engagent à se conformer et à respecter le code de

conduite éthique et professionnelle édité par PMI. En effet, PMI a développé un code de déontologie et d’éthique professionnelle ancré sur quatre valeurs universelles que sont la responsabilité, le respect, l’équité et l’honnêteté. Lorsqu’il travaille sur un projet, le manager doit donner l'exemple, agir dans le respect du code déontologique et créer un environnement éthique qui encadrera les choses à faire ou à ne pas faire. Il est essentiel que le manager souligne et passe en revue le code de déontologie de l’organisation dès le début du projet. L’une des caractéristiques des « gold » managers de projet est de toujours

respecter ces codes éthiques et déontologiques qui garantissent honnêteté et intégrité dans leurs efforts pour faire aboutir le projet et cela même là où beaucoup auraient envie d’abandonner le projet. Ce sont ces Managers de Projet qui tiennent bon à la barre et ne quittent pas le navire en plein tempête, conscients que même si la tempête peut durer longtemps, l’accalmie finit toujours par arriver.

Le management de projet est l’application d’Outils et de Techniques Toute profession dispose des outils et techniques qui lui sont propres, en support de ses méthodologies. Un chirurgien possède ses propres outils et techniques d’opération. Un policier, ses propres outils et techniques de

profilings d’individus, non-basé sur un profil ou quota racial. Un chef, ses propres outils et techniques de cuisine. Un Manager de Projet détient également ses propres outils et techniques. On est un bon chirurgien, un bon policier ou un bon cuisinier si l’on manie proprement ses outils et techniques. Un bon Manager de Projet sait utiliser les outils et techniques adaptés aux activités d’un projet. Il parvient également à garder dans son armoire les techniques à utiliser au quotidien, afin de débloquer une situation, de faire preuve de créativité, de trouver de nouvelles manières de régler les problèmes. Mais encore faut-il les connaitre avant de les

posséder. Or, cette connaissance n’est pas suffisante si on ne sait pas la mettre en pratique. N’oublions pas que l’efficacité d’un outil ou d’une technique dépend d’abord du potentiel de celui ou de celle qui l’utilise. Un imbécile avec un outil reste toujours un imbécile. Un chirurgien n’est bon que s’il utilise efficacement les outils et techniques propres à sa science. De même, un Manager de Projet ne peut être bon que s’il applique de façon efficace les techniques et outils de son domaine. Le management de projet comprend donc l’application efficace d’outils et de techniques aux activités du projet. Manager un projet revient à utiliser les

bons outils et les bonnes techniques pour planifier, estimer, communiquer, analyser, suivre ou contrôler les activités du projet. Quelle technique utiliser pour développer les échéances des activités ? L’élaboration progressive ou le Rolling Wave (Planification par vagues)? Quelle technique sert à estimer les coûts ? Préfère-t-on utiliser une approche Bottom-Up ou Top-Down ? Nécessite-t-on une estimation paramétrique ou l’estimation par analogie convient-elle davantage? Pour manager un projet, il convient d’utiliser les bons outils et les bonnes techniques pour mesurer la performance du projet par des techniques de l’Earned

Value (Valeur Acquise), par exemple. Sans mesurer, il est impossible de manager. On procède alors à du management entre l’état désiré, l’état actuel et l’état prévisionnel. Il faut donc évaluer les avancements du projet (Schedule Value, Schedule Performance Index) et s’occuper du management en conséquence, selon qu’on accuse un retard ou une avance par rapport au baseline. Si le projet prend du retard, quel outil choisir : le Fast Tracking (Exécution accéléré par Chevauchement) ou le Crashing (Compression des délais) pour compresser le planning sans réduire le scope ? Quelle technique utiliser pour mesurer les menaces afin

qu’on puisse faire du management en conséquence selon la probabilité que ce risque devienne un problème et selon son impact sur le projet ? On compte les dépenses engagées, on estime les coûts nécessaires pour terminer le projet (Estimation At Completion), et on fait le management en conséquence selon le budget disponible. Ces données s’évaluent grâces à des outils dédiés à l’application de la technique appropriée. Bien sûr, un Manager de Projet doit pouvoir choisir les bons outils et les bonnes techniques selon la taille du projet. On ne tue pas une mouche avec de l’artillerie lourde.

Le management de projet implique énormément de données dynamiques, d’informations, de mesures et d’analyses, ainsi que de communication. Afin de les traiter proprement, les managers de projet font appel aux outils et techniques de management de projet. Le Manager de Projet et son équipe utilisent les techniques pour exécuter les activités liées au projet, et se servent des outils dans l’application de ces techniques. Les paragraphes qui vont suivre auront pour objectif de passer en revue certaines techniques et outils que l’on peut appliquer au quotidien pour manager les activités du projet.

Puisque cet ouvrage est dédié au management de projet international impliquant une équipe virtuelle éparpillée sur différents sites, voire continents, où la langue de travail est souvent celle de Shakespeare, nous utiliserons les termes en anglais avec un sous-titre français entre parenthèses, afin de disposer d’une terminologie commune. L’auteur, votre humble serviteur, présente d’ores et déjà ses excuses aux défenseurs de la pureté de la langue française et aux gardiens de l'orthodoxie orthographique.

Technique

Technique: Procéd par une ressource h de création d’un pr d’un service et qui outils (source PMBo Définition 16: Technique

Le Manager de Projet et les membres de l’équipe feront appel à ces techniques afin de faciliter et de mener à bien les activités liées au projet. Ces ressources peuvent utiliser un ou plusieurs outils, tout en appliquant la même technique.

Technique de collecte

d’information et d’aide à la prise décision Lorsque l’on manage un projet, il faut collecter beaucoup d’informations qui souvent apportent une aide précieuse dans les prises de décisions. Jugement d’Expert Le jugement d’expert est la technique à laquelle le Manager de Projet fait le plus souvent appel.

Jugement d’Expert expertise dans un cha connaissance, une disc fourni par un groupe d’expertise, l’expérienc PMBoK®) Définition 17: Jugement d'expert

Ces experts peuvent être des consultants externes ou des membres du PMO, mais ils sont en tout cas des connaisseurs dans leurs domaines, pour intervenir et véhiculer leur expertise sur une partie du projet. Ils peuvent apporter un complément de réponse lorsque les données disponibles sont peu nombreuses ou inadaptées. Dans certains cas, ils constituent la seule source d’information disponible dans un processus décisionnel. On peut obtenir les jugements d’experts à travers plusieurs canaux de communication, comme par un simple entretien en face-à-face ou téléphonique, par prestation de service, par une étude

statistique, etc. Il est évident qu’avec cette technique, le Manager de Projet utilise la consultation des experts comme moyen décisionnel. Enfin, dans la quatrième édition du PMBoK®, cette technique est utilisée dans les sept domaines de connaissance sur neuf et dans au moins dix-huit processus sur les quarante-deux existants (voir tableau ci-dessus).

Processus

1. 2. 3. 4. 5.

Elaborer la Charte du projet Elaborer le plan de Management du pr Diriger et piloter l’exécution du projet Suivre et Maitriser les activités du pro Mettre en œuvre la maitrise intégrée d changements de scope 6. Clore Projet ou phase

7. Définir le scope 8. Définir les activités 9. Estimer les ressources nécessaires aux activités 10. Estimer la durée des activités

11. Estimer les coûts

12. Déterminer le budget 13. Identifier les stakeholders 14. Identifier les Risques 15. Mettre en œuvre l’analyse Qualitative

risques 16. Mettre en œuvre l’analyse quantitative risques 17. Planifier les Réponses aux Risques

18. Planifier les approvisionnements Brainstorming

Brainstorming : une données et idées, f participants membres

souvent utilisée pour idées et des solutions PMBoK®) Définition 18: Brainstorming

C’est une technique participative qui s’appuie sur la créativité spontanée des participants. Sur un projet, on utilise cette technique le plus souvent pour : Collecter les exigences Déterminer les différentes alternatives pour exécuter les activités d’un projet Planifier le plan de qualité d’un projet Résoudre les problèmes survenus lors du projet

Identifier les risques sur un projet Trouver la solution à un problème Cette activité heuristique peut être animée par le Manager de Projet. C’est un exercice assez ludique où la phase de production intellectuelle intense plonge le groupe dans un état d’excitation. Un tel exercice produit un effet teambuilding car il modifie les relations entre les membres du groupe, ce qui crée des liens et fait ressentir une grande solidarité dans la créativité, lorsque chacun s'aperçoit que les autres ont des idées. Pour qu’une session de brainstorming fonctionne, il faut respecter ces quelques règles de bases:

Exprimer toutes ses idées librement sans arrière-pensée Ne pas critiquer ni discuter les idées énoncées Donner le droit à chacun de "piller" les idées des autres Exprimer une seule idée à la fois par personne Faire en sorte que chacun parle à tour de rôle, pas tous à la fois

Identification des risqu

Au début et tout au long d menaces ainsi qu’un plan pour parer à matérialisent. Tout problème susceptibl projet est un danger. Il s’agit d’identi demain.

En utilisant la technique de brainstorm room l’équipe projet, certains autres ex 1. Dresser une liste exhaustive des projet

2. Évaluer la probabilité d'apparition

associant une pondération (8: Possible, 1: Peu probable) 3. Mesurer le niveau d’impact si le Haut, 2: Medium, 1: Faible) 4. Déterminer le poids du risque niveau d'impact. On obtient un p d'un poids supérieur doivent êtr projet, et sont à surveiller avec inférieur peuvent généralement ê Critique, 32: Haut, 16: Medium, ID

Problème

Potentiel

spécifique 1 2 3 4

Réseau WAN, LAN Ressources victimes du syndrome de la chaise vide Mauvaises définitions des besoins Manque de support des stakeholders

Ensuite, l’équipe peut continuer le suivantes : 1. Suggérer les causes probables 2. Suggérer les mesures préventives 3. Pour chaque plan de mitigation, savoir le moment auquel on contingence ID 1

Cause Probable Absence

Mesure Préven de contingence de Définir une p

QoS

2

3

4

QoS, Renforcer les év réseau Turnover très Redistribution important Plan de Assistance exter Manque Choisir une mét d’expertise projet perm développement AGILE, SCRUM Passivité Définir un management stakeholders

Le résultat de cet exercice est à insér compte dans les estimations de coûts contingence. Exemple 104: Brainstorming - Identification des

risques

Avec la banque d’informations générée comme résultat d’une telle séance, le Manager de Projet utilise comme moyen décisionnel la consultation, en comptant sur l’intelligence et la créativité de groupe. Technique Delphi

Delphi Technique : Te utilisée en recherche question considérée. L anonyme, aidés par u questionnaire pour so importants du projet. soumises à nouveau a répétant le processus, après quelques itération

Définition 19: Techniques Delphi

Cette technique permet de parvenir à une décision par consensus. En effet, elle contribue à réduire la distorsion des données et surtout à éviter qu’une personne en particulier ait une influence indue sur la décision à prendre. Il s’agit de rallier à travers plusieurs itérations les points de vue et jugements de plusieurs experts. Dans le meilleur des cas, le résultat final est une solution que les experts n’auraient pas atteinte individuellement. Car une décision prise par un groupe d’experts structuré est généralement plus fiable que le choix de communautés non structurées ou d’individus isolés.

À l'origine développé comme outil de prévision, il a été créé par des militaires américains dans les années 50 afin d'estimer les effets probables d'une attaque à la bombe atomique massive sur les Etats-Unis. Au milieu des années 60, les chercheurs ont commencé à faire appel à cette technique à des fins de prévisions technologiques. Depuis lors, son utilisation s’est étendue à d'autres disciplines comme méthode d'identification et de résolution de problèmes. Plusieurs compagnies utilisent cette technique comme outil de prévision d’événements ou des tendances du marché en termes d’innovations

technologiques et de leurs applications dans les différents domaines de la vie. Bell Canada a été le premier à l’employer pour déterminer la tendance en termes d’évolution future des communications visuelles pour les télécommunications. La technique Delphi comporte plusieurs étapes impliquant des participants qu’ils se trouvent dans la même salle ou en visioconférence, ou encore isolés les uns des autres afin d’éviter toute influence, puisque certains peuvent prendre part au projet de façon anonyme. Ces participants sont employés par la même compagnie ou sont des experts externes choisis

pour leur connaissance approfondie. Les étapes se déroulent souvent comme suit : 1. Articulez le problème pour lequel ces experts sont réunis. 2. Demandez aux participants de fournir des solutions possibles à travers une série de questionnaires conçus avec soin, délimitant le paramètre de leur réponse. 3. Les participants répondent en remplissant de façon indépendante le questionnaire. 4. Les réponses du premier questionnaire, ainsi que les argumentaires ayant conduit à ses réponses, seront compilées en un

seul document de synthèse distribué à tous les participants. 5. Après avoir examiné la synthèse des premiers résultats, les participants devront présenter de nouvelles solutions en revoyant leurs précédentes réponses et en se basant sur la synthèse 6. Les réponses du second questionnaire, ainsi que les argumentaires ayant conduit à ses réponses, seront compilées en un seul autre document de synthèse distribué de nouveau à tous les participants 7. Après avoir examiné la synthèse des deuxièmes résultats, les participants

devraient présenter de nouvelles solutions en revoyant leurs précédentes réponses et en se basant sur cette synthèse 8. On réitère le processus jusqu’à l’obtention d’un consensus survenant généralement après 4 ou 5 itérations Sur un projet, en se basant sur les informations et connaissances disponibles, on utilise cette technique le plus souvent pour : Collecter les exigences du projet Prédire des situations ou des événements à venir dans le déroulement du projet Identifier les risques sur un projet

Technique de développement du planning

Figure 65 : Projet ToIP

On peut organiser les activités du projet ToIP en séquence comme suit :

Figure 66 : Activités en séquence

Ou la description des activités est donnée par le tableau suivant : WBS Description des Activités A : Déploiement de la partie centrale (PC) dans un centre de données 1 (Datacenter) en Europe, d’un

2

PBX et d’un server Instant Communicator ; B : Déploiement du site en Afrique, comprenant 200 téléphones IP et un Media Gateway, que l’on rattache par la suite à la partie centrale (A) ; C : Déploiement du site en Asie, comprenant 300 téléphones IP et un Media

3

4

Gateway que l’on rattache par la suite à la partie centrale (A) ;

D : Déploiement d’un site en Europe, comprenant 100 téléphones IP, un Media Gateway et un client Instant Communicator que l’on rattache par la suite à la partie

5

centrale (A) ; E : Déploiement d’un site en Amérique du Nord, comprenant 200 téléphones IP, un Media Gateway et un client Instant Communicator, que l’on rattache par la suite à la partie centrale (A).

On peut voir les activités se dérouler les unes après les autres et voir que la durée totale pour effectuer le projet sera probablement de 82 jours. Dans un rêve,

tout se passe comme on se l’imagine, mais dans la réalité, chaque jour nous réserve sa petite surprise, bonne ou mauvaise. Les activités se déroulent rarement comme prévu, surtout sur un projet impliquant de nombreux facteurs environnementaux internes ou externes à l’entreprise, que l’on ne contrôle pas, mais pour lesquels on peut toutefois anticiper la survenance sur le projet. Il est donc nécessaire d’effectuer des estimations dans le planning, en tenant compte des imprévus de la vie d’un projet et des incertitudes qu’ils causent sur la durée de chaque activité. Pour ce faire, il existe plusieurs techniques qui consistent à combiner l’estimation la

plus optimiste, la plus pessimiste ainsi que la plus probable. PERT

PERT : Technique d moyenne pondérée pessimistes, et très p pèse sur les estimatio (Source PMBoK®) Définition 20: PERT

Avec: EPERT est l’estimation de la durée d’une activité en appliquant la technique PERT. Eoptimiste est l’estimation la plus optimiste de la durée d’une activité

du projet. Eprobable est l’estimation la plus probable de la durée d’une activité projet. Epessimiste est l’estimation la plus pessimiste de la durée d’une activité du projet. Déviation Standard On peut également, à travers la déviation standard ( ), évaluer la probabilité que l’activité se déroule dans les temps estimés ainsi que calculer les risques associés à l’estimation sur la durée de l’activité:

On dit qu’à : +/-1 : il y a 68,3% que l’activité se déroule à la période estimée par l’estimation PERT. +/-2 : il y a 95,5% que l’activité se déroule à la période estimée par l’estimation PERT. +/-3 : 99,7% que l’activité se déroule à la période estimée par l’estimation PERT. On peut contrôler les risques également en fixant une limite à +1 par exemple, à partir de laquelle on met en place un plan pour parer à toute éventualité de retard dans le planning. Technique des 3 Points

3 Points : Techniqu applique une moye optimistes, pessimiste incertitude pèse sur sous-jacentes. (Source Définition 21: Technique des 3 Points

Avec: E3Points est l’estimation de la durée d’une activité en appliquant la technique 3 Points Eoptimiste est l’estimation la plus optimiste de la durée d’une activité du projet Eprobable est l’estimation la plus probable de la durée d’une activité

du projet Epessimiste est l’estimation la plus pessimiste de la durée d’une activité du projet

Le tableau ci-dessous montre les différentes estimations de la durée de chaque activité du projet. Sites

Tâches A.1 Expédition

A : Datacenter

B : Site B

A.2 Installation A.3 Configuration A.4 Tests et Recette B.1 Expédition B.2 Installation B.3 Configuration B.4 Tests et Recette C.1 Expédition

E

C : Site C

D : Site D

E : Site E

C.2 Installation C.C Configuration C.4 Tests et Recette D.1 Expédition D.2 Installation D.3 Configuration D.4 Tests et Recette E.1 Expédition E.2 Installation E.3 Configuration E.4 Tests et Recette

Exemple 105 : Estimation de la durée des activités avec les techniques PERT, 3 Points et

Quant à la durée totale du projet, on peut

en tirer les conclusions suivantes : Dans le meilleur des cas, le projet dure au total 44 jours. Dans le pire des cas, le projet dure au total 177 jours. Dans les cas les plus probables, le projet dure au total 82 jours. Avec l’estimation PERT, le projet dure au total 91,5 jours. Avec l’estimation des 3 points, le projet dure 1101 jours. Élaboration progressive Plus on a d’informations sur les activités, mieux on peut affiner le planning. Un manager de projet doit pouvoir manipuler la technique de l’élaboration progressive des plannings.

Élaboration progre continu d’un plan informations détaillée sont disponibles dura meilleure précision planification est o successives. (Source Définition 22: Elaboration Progressive

Cette technique permet d’affiner non seulement le planning mais également les estimations sur les coûts. La plupart des managers de projet commencent par un planning qu’ils affinent au fur et à mesure du temps de l’information disponible. On peut tout aussi bien se servir d’un planning comme baseline ou comme référence sur

base de laquelle on mesurera tout avancement ou déviation ainsi que la performance sur le projet. PDM (Precedence Diagramming Method) ou méthode des antécédents Certains managers de projet commencent directement par les outils logiciels disponibles sur le marché pour présenter leur planning. Chaque Manager de Projet se doit de comprendre le mécanisme derrière ces outils. Pour établir un planning, il existe plusieurs représentations telles que les suivantes : La technique GANTT : planning à barres La technique PERT : méthode des

potentiels étapes et planning des tâches Le réseau des antécédents : méthode de planification dans laquelle l'exécution d'une tâche est conditionnée par l'accomplissement d'une ou plusieurs autres tâches d'un réseau d'activités, toutes liées entre elles.

PDM (Precedence D des antécédents est les activités du p rectangles (nœuds). activités sont reliées montrer la séquenc réalisées. Définition 23: Méthode des antécédents

Avec la méthode des antécédents, le chevauchement ou le recouvrement d'activités peut se représenter grâce à quatre sortes de liaisons logiques qui sont associées entre elles par un délai minimum comme suit : SF (Start to Finish) ou DF (Début-Fin) : c’est un lien logique où la fin de l’activité successeur dépend du démarrage de l’activité antécédente. Cette relation logique est rarement utilisée et c’est la raison pour laquelle elle n’est pas illustrée dans l’exemple ci-dessus. Je ne vous en parle que pour vous informer de son existence.

SS (Start to Start) ou DD (DébutDébut) : c’est un lien logique où le démarrage de l’activité successeur dépend du démarrage de l’activité antécédente. Dans le diagramme cidessus, l’activité B1 ne peut commencer que si l’activité A1 a commencé. Au plus tard, B1 peut commencer 8 jours après que l’activité A1 ait commencé.

Figure 67: Lien logique Début à Début

FS (Finish to Start) ou FD (FinDébut) : c’est un lien logique où le démarrage de l’activité successeur dépend de la fin de l’activité antécédente. C’est le lien logique qui est le plus souvent utilisé. On voit par exemple ci-dessous que ni l’activité A4 ni l’activité B3 ne peut commencer si l’activité A3 n’est pas

achevée. La fin de l’activité A3 permet le début des activités A4 et B3. On voit également une relation FD entre B3 et B4.

Figure 68: Lien logique Fin à Début

FF (Finish to Finish) ou FF (Fin-

Fin) : c’est un lien logique où la fin de l’activité successeur ne peut avoir lieu tant que la fin de l’activité antécédente n’a pas encore eu lieu. Dans l’exemple ci-dessous, l’activité D ne peut se terminer que si l’activité C est terminée.

Figure 69: Lien logique Fin à Fin

Décalage avec Avance (Lead) – Décalage avec Retard (Lag) On peut également manipuler le planning en introduisant un retard ou une avance entre l’activité précédente et l’activité successeur.

Exemple 106 : Lead et Lag sur un planning

Dans l’exemple ci-dessus, la durée totale du projet est de 79 jours. Deux

techniques Lead (Décalage avec avance) et Lag (Décalage avec retard) ont été introduites.

Lead : Modificatio d’accélérer l’activité su Lag : Modification d’ de l’activité successeur Définition 24: Lead - Lag

Le Lead a été utilisé de façon à avancer de 10 jours le début de l’activité B (déploiement du site Afrique) avant la fin de l’activité A (déploiement de la partie centrale). On peut ainsi accélérer le déroulement des activités. Le Lag a été utilisé de façon à laisser 5

jours entre la fin de l’activité B et le début de l’activité C. Les 5 jours peuvent signifier une réserve au cas où les activités A et B prennent du retard et 5 jours peuvent constituer une bonne réserve de temps. Chemin critique Le Manager de Projet va être également amené à utiliser une technique pour déterminer le degré de flexibilité pour qu’un projet se termine dans les délais prévus. Le plus souvent, on utilise la technique du chemin critique.

Chemin Critique : La technique d'établissemen les activités les moins fle marges. Ces calculs de

déterminer la séquence d'où découle la date de d'activités la plus longu retard accusé dans une critique a une incidence Définition 25: Chemin Critique

Le Manager de Projet doit déployer ses meilleures ressources, maîtriser et surveiller particulièrement les risques sur le chemin critique du projet. Toute déviation sur le chemin critique entraîne une avance (rarement) ou un retard (certainement) sur la durée du projet. Dans l’exemple suivant (Exemple 107 : Diagramme des antécédents avec des contraintes), le chemin critique est A1-

>A2->A3->A4->C->D->E pour une durée totale du projet de 52 jours. Les activités B1 et B2 ont une marge libre de 8 jours. Ce qui voudrait dire qu’on peut se permettre un retard de 8 jours sans mettre en danger le délai de livraison du projet. Les contraintes temporelles et de ressources Un projet ne se déroule jamais dans les conditions « normales », car il peut y avoir un deadline forcé, une dépendance sur un autre projet ou encore d’autres contraintes comme suit : des contraintes temporelles : certaines tâches représentent des impératifs de temps à prendre en

compte, comme par exemple la durée allouée à des tâches qui n’est pas compressible (livraison d’équipements, formation, etc.), ou encore par soucis de cohérence comme, par exemple, l’installation qui ne peut commencer que quand les livraisons des équipements sont effectuées ; des contraintes de ressources : l’utilisation des ressources par tâche est limitée dans sa quantité et sa nature. Par exemple, neuf femmes ne peuvent accoucher d’un bébé en un mois, il faudra toujours neuf mois à une femme pour mettre au monde un bébé. Il existe également la contrainte de disponibilité des

ressources. Sur un projet, un manager doit savoir manipuler les contraintes et peut s’appuyer sur les types de contraintes suivants: LF (Late to Finish ou Date de fin au plus tard) : c’est la date ultime à laquelle une activité doit être achevée pour pouvoir respecter les délais prévus pour finir le projet. Les valeurs de LF se calculent en partant de la fin des activités vers le début. Dans l’exemple ci-dessous, 52 jours représentent la durée totale du projet, donc le paramètre LF pour la dernière activité sur le planning, en l’occurrence E, ne peut être qu’égal à

52. À partir de cette dernière activité, on remonte dans le temps et on détermine le LS de l’activité, en l’occurrence E, qui n’est autre que LS = (LF-durée de l’activité E). Le LF de l’activité prédécesseur est égal au LS de l’activité successeur. LS (Late Start ou Date de début au plus tard) : c’est la date à laquelle une activité doit démarrer au plus tard. Le LS se calcule à partir du LF comme expliqué ci-dessus. ES (Early Start ou la date de début au plus tôt) : c’est la date à laquelle une activité peut démarrer

au plus tôt. Cette date peut changer à chaque fois qu’il y a une modification au plan de management au fur et à mesure que le projet avance. Le ES se calcule en partant du début. EF (Early Finish ou encore la date de fin au plus tôt) : c’est la date à laquelle une activité est terminée au plus tôt. Cette date peut changer à chaque fois qu’il y a une modification au plan de management et au fur et à mesure que le projet avance. Le EF se calcule à partir du ES, en effet EF = ES + durée de l’activité. Le EF de l’activité

prédécesseur est égal à l’ES de l’activité successeur. Free float ou marge libre est le temps maximum dont une activité peut être retardée sans retarder la date de début au plus tôt de l’une des activités consécutives. Dans l’exemple ci-dessous, la marge libre est de 28 pour les activités B3 et B4. Float/Slack ou marge totale est le temps total maximum de retard que le planning peut se permettre de prendre sans rendre critique le délai du projet. Il suffit d’additionner toutes les marges libres.

Exemple 107 : Diagramme des antécédents avec des contraintes

Planification par vague (Rolling Waves)

Rolling waves vague, variante progressive, dan terme est planifi

structure de déco à long terme es élevé. La planific deux autres péri pendant l’exécuti (Source PMBoK® Définition 26: Planification par vague (Rolling Waves)

Dans l’exemple ci-dessus (Exemple 107 : Diagramme des antécédents avec des contraintes), le planning est détaillé pour les activités à court terme tandis que le travail à moyen et long termes sont aussi planifiés mais pas en détails. En effet, les activités A sont détaillées en A1, A2, A3 et A4.

Fast Tracking - Exécution accélérée par chevauchement Quand la contrainte de temps est pressante et qu’il faut réduire la durée des activités, on peut faire appel à du Fast Tracking.

Fast tracking : une chevauchement. On com les tâches initialement (Source PMBoK®) Définition 27: Fast Tracking - Exécution accélérée par chevauchement

Il ne s’agit pas ici de réduire le scope, encore moins de faire un scope creep, mais simplement d’effectuer les tâches qui devaient se dérouler les unes après

les autres en parallèle. L’inconvénient est qu’on augmente les risques en exécutant plusieurs tâches en parallèle et on peut se poser la question de la disponibilité des ressources. Le résultat d’un fast tracking sur un planning comme celui ci-dessus est la réduction de 30 jours de la durée totale des activités comme illustrer dans le schéma suivant:

Figure 70: résultat d'un fast tracking d'un planning

Crashing – Compression des délais Quand la mise en parallèle des activités n’est plus possible pour réduire la durée totale du projet, on peut toujours faire appel à la technique de la compression des délais.

Crashing : une techn du projet ; des actio durée totale de l’échéa Définition 28: Crashing – Compression des délais

Pour réduire la durée totale d’un planning, on réduit avec cette méthode et après analyse des différentes alternatives, la durée d’une ou de plusieurs activités. En effet, on analyse le coût d’un crash par jour de chacune des activités et on choisit de l’appliquer sur l’activité dont le coût du crash est moindre. Cela a souvent comme conséquence l’augmentation des ressources affectées à l’activité, ainsi qu’une augmentation des coûts, à savoir le coût de chaque crash par jour.

Coût Délai Délai du WBS Tâche prévu du crash Code (jour) crash par jour A Datacenter 20 j 5j 1500,00 € B Site B 16 j 4j 800,00 € C Site C 16 j 4j 900,00 € D Site D 14 j 4j 750,00 € E Site E 16 j 5j 600,00 € Total 82 j 22 j Exemple 108 : Crash du planning

Dans cet exemple, le délai prévu pour le projet est de 82 jours. Maintenant, que peut-on faire pour compresser ce délai et réaliser le projet en 72 jours ? On peut utiliser la technique du fast tracking comme dans l’exemple cidessus, mais on peut également employer celle du crashing. Pour cela, le tableau indique déjà que le nombre de crash maximum que l’on peut se permettre est de 22 jours. En effet, chaque activité a un maximum de crash autorisé. Le crash peut être l’addition de plusieurs ressources pour la même activité. Cela a donc un coût, et le coût du crash par activité n’est pas le même. Il s’agit ici d’évaluer le coût de chaque

crash et de choisir de compresser l’activité dont le coût du crash est moindre. Dans notre exemple, il est question d’avoir besoin de 10 jours de crash pour compresser notre planning de 82 jours à 72 jours. On peut enlever les 5 jours de l’activité E, qui correspond au coût du crashing le moins cher, ensuite on peut encore enlever les 4 jours de l’activité D, dont le coût correspond au deuxième moins cher et enfin, on peut enlever 1 jour de l’activité B dont le coût correspond au troisième moins cher. Après analyse et application de la technique du crashing, on peut obtenir le

résultat suivant : WBS Code

A B C D E

Tâche

Datacenter Site A Site B Site C Site E Total

Délai prévu

Délai après crash

20 j 16 j 16 j 14 j 16 j

20 j

84 j

82 j

15 j 16 j 10 j 11 j

Exemple 109 : Résultat après crash du planning

La méthode de la chaîne critique La méthode de la chaîne critique : elle met l’accent sur les ressources

humaines requises pour exécuter les tâches du projet. Une marge de sécurité (un buffer) est ajoutée sur chacune des tâches afin d’éviter les gaspillages générés par le syndrome de l’étudiant, la loi de Parkinson ou encore les mauvaises allocations multitâches de ressources. (Source :

PMBoK®) Définition 29: La méthode de la chaîne critique

Cette technique, inspirée de la Théorie des Contraintes d’Eliyahu M. Goldratt, consiste à intervenir au niveau de chacune des tâches qui, mises ensemble, forment le planning. En effet, avec cette méthode, les plannings sont vraiment très détaillés car ils s’établissent à partir d’un grand nombre de tâches, sur chacune desquelles chaque responsable ajoute une marge de sécurité. Le planning est respecté si chaque tâche est exécutée dans les délais prévus. Le délai pour exécuter une tâche est calculé en fonction des contraintes des ressources prévues pour la tâche. À

ce délai d’exécution d’une tâche, on rajoute une marge de sécurité (un buffer). La méthode de la chaîne critique additionne chaque délai du buffer introduit dans chacune des tâches, qui n’est pas alloué au temps de travail, pour manager les incertitudes. Et, au final, le Manager de Projet va gérer la quantité de buffers restants par rapport aux tâches restantes à réaliser pour livrer son projet dans les délais impartis. Cette quantité de marges de sécurité, réparties dans les différentes tâches, a pour but de lutter contre les syndromes de l’étudiant, la loi de Parkinson et les mauvaises allocations multitâches des ressources.

En effet, les arrêts-reprises dus à l’allocation des ressources à plusieurs tâches peuvent avoir un effet négatif sur la ressource, comme la perte de concentration ou encore le temps d’adaptation. Ainsi, l’introduction d’un buffer pour permettre une bonne transition à la ressource, peut également être une bonne solution pour que la ressource termine ses tâches dans les délais prévus.

Le syndrome de l'étudian que nécessaire devant lui en reportera le démarrag l'intéressent davantage.

Loi 7 : Syndrome de l'étudiant

Il existe également des ressources, manifestant le syndrome de l’étudiant, qui attendent toujours la dernière minute pour exécuter leurs tâches. Combien de fois n’a-t-on pas entendu une ressource se plaindre comme un étudiant quand on lui annonce une tâche à faire du jour au lendemain ? La ressource va demander plus de temps pour effectuer sa tâche, tout comme l’étudiant va demander davantage de temps pour réviser son examen, mais ce n’est pas pour autant que cette ressource ou l’étudiant va se mettre au travail ou réviser, il attendra la dernière minute, à savoir la veille. La méthode des chaînes critiques offre une

approche pour lutter contre ce syndrome.

La Loi de Parkinson con une tâche, même si le temp moindre. Loi 8 : Loi de Parkinson

Quand une tâche est terminée au bout de 3 jours alors que le délai prévu pour son exécution est de 9 jours, certaines ressources manifestent un comportement décrit par la loi de Parkinson. Elles auront ainsi tendance à occuper tout le délai prévu à des choses qui les intéressent, et à ne déclare leur tâche comme terminée qu’au bout du dernier jour. Ce comportement est très fréquent chez les créatifs ou ceux qui réalisent vraiment des choses compliquées.

Le syndrome du calen prévue pour démarrer une Loi 9 : Syndrome du calendrier

Enfin, il existe le syndrome du calendrier : certaines ressources vont attendre la date de début prévue pour une tâche avant de lever le petit doigt, même si la tâche est critique et qu’elles sont disponibles avant. Alors, si on combine la loi de Parkinson avec les syndromes de l’étudiant et du calendrier, pensez-vous que le projet respectera le planning et sera livré dans les délais impartis ? La méthode des chaînes critiques y apporte un élément de réponse.

Technique de Mesure de Performance et de Prévision Technique de la Valeur Acquise ou Earned Value (EV) Il n’y a pas de management de projet si l’on ne mesure pas régulièrement la performance du projet en termes de planning et de coûts. C’est sur la base de ces évaluations que l’on fait réellement du management de projet en introduisant les mesures correctives ou préventives afin de permettre la réalisation du projet dans les délais et budgets prévus. Earned Value Technique (EVT) : technique de la

valeur acquise pour mesurer la performance du travail, utilisée pour établir la référence de base des mesures de performances. Définition 30: Earned Value Technique (EVT) technique de la valeur acquise

La technique de la valeur acquise (EV) a été créée par le gouvernement américain pour contrôler les paiements sur les avancements des travaux afin d’éviter de payer plus que la valeur réelle du travail qui devait être fait. Cette technique

permet de mesurer un certain nombre de paramètres que l’on décortiquera dans ce paragraphe. Pour ce faire, il faut considérer les suivants : La valeur planifiée ou Planned Value (PV) : c’est la valeur planifiée ou encore le coût budgété du travail prévu. C’est le coût prévu dans le budget pour les activités planifiées. La valeur acquise ou Earned Value (EV) : c’est la valeur acquise ou encore le coût budgété pour le travail effectué. Le coût réel ou Actual Cost (AC) : cette valeur correspond au coût réel

du travail effectué. On fait ici l’addition de tous les coûts imputables au projet pour réaliser le travail effectué. Afin de mieux illustrer le concept, utilisons l’exemple de projet déploiement ToIP.

Planned Value (PV) du projet ToIP Le Manager de Projet a planifié de déployer le projet ToIP en 5 mois comme suit :

Mois PV Mois 25k€ 1 Mois 40k€ 2

Mois

Valeur Planifiée (PV) Tâches planifiées

3

60k€

Mois 80k€ 4

Mois 105k € 5

Exemple 110 : Valeur Planifiée (PV)

Valeur Acquise (Earned Value) et Coût Réel au cours des 3 premiers

mois Mais un projet ne se déroule jamais comme planifié, le tableau ci-dessous montre les valeurs acquises ainsi que les coûts réels durant les 3 premiers mois du projet. Valeur Acquise (EV) Mois EV Mois 25k € 1 Mois 35k € 2

Mois 50k

Tâches accomplies

3

€

Exemple 111 : Valeur acquise (Earned Value) et coût réel (Actual Cost)

Performance du projet en termes de coûts et de planning Le Manager de Projet peut mesurer la performance de son projet par mois avec les variables suivants : Schedule Variance (SV) [SV=EV-PV] : la variance entre le coût budgété du travail effectué (EV) et le coût budgété du travail prévu (PV). Le SV représente

l’écart des délais qui mesure la performance en termes d’avancement du planning. Schedule Performance Index (SPI) [CPI = ] : la performance du projet en termes de planning. En effet, le SPI représente l’Indice de performance des délais qui mesure les magnitudes de variations en termes de planning. Cost Variance (CV) [CV=EVAC] : la variance entre coût budgété du travail effectué (EV) et le coût réellement dépensé sur le projet à un moment donné dans le

temps Cost Performance Index (CPI)

[CPI =

] :la performance ou

encore le rendement du projet en termes de coût. Paramètre de mesures de performance

Mois 1

Mois 2

Mois 3

SV SPI CV CPI

0k€ 1 -4k€ 0,86

-5k€ 0,87 -7k€ 0,83

-10k€ 0,83 -15k€ 0,79

Mois 1 : le Manager de Projet a

bien managé son planning durant le premier mois (SV=0 et SPI = 1). En revanche, il a dépensé 4k€ de plus que prévu, et pour 1€ investi sur le projet, il ne peut récupérer que 0,86 centimes d’Euro. Le Manager de Projet doit pouvoir expliquer ce surcoût à son steering committee. Mois 2 :le projet commence à prendre du retard avec seulement 87% de travail effectué comparé au travail prévu (SV=-5k€ et SPI = 0,87) et pour ne pas arranger les choses, le projet représente encore un surcoût de 7k€, soit 3k€ de plus que précédemment. Ceci ne veut pas

dire forcément que le Manager de Projet et l’équipe projet font mal leur travail. Le projet peut être ralenti parce qu’il est en attente de facteurs sur lesquels l’équipe n’a pas de contrôle et qui n’ont pas été identifiés. Ce sont les Unknownunknown que l’on a vu en détails dans l’étude des risques. Toutefois, le Manager de Projet devrait pouvoir expliquer ce surcoût et, surtout, présenter des mesures correctives pour corriger le tir et des mesures préventives afin de prévenir tout risque d’amplification de la situation. En général, c’est en début de projet que l’on dépense le plus.

Mois 3 : le projet dans sa globalité continue à avoir du retard (SV=-15k €), mais le SPI montre que le retard du mois 2 a été réduit légèrement. Les mesures prises par le Manager de Projet sont visibles en termes de planning. En revanche, en termes de coût, cela s’aggrave : le surcoût a doublé, le projet dépense plus que prévu, on perd de l’argent, le budget du projet commence vraiment à saigner. Le projet vit au-dessus de ses moyens. Le Manager de Projet devrait pouvoir expliquer ce surcoût, et proposer des mesures prises dans le futur pour contrôler et réduire ce

surcoût. En espérant que ces surcoûts ne soient pas dus à des dépenses en nourriture et boissons alcoolisées. Mesure de Prévisions en termes de délai et de budget Avec la méthode des EVT, on peut également estimer les prévisions en termes de budget et de délai. On peut estimer des situations ou des événements à venir dans le déroulement du projet, à partir d’informations et de connaissances disponibles au moment où les prévisions sont effectuées. Pour ce faire, on a besoin des paramètres suivants : Budget at Completion (BAC) : budget final initialement planifié

pour réaliser le projet. Estimate at Completion (EAC) [EAC=BAC/CPI]: coût final estimé à un temps donné où l’on fait des prévisions sur le coût total à la fin du projet. Il est très important de connaître ce paramètre, surtout quand le surcoût commence à augmenter mois après mois, car si cela se trouve, le budget initialement prévu (dans notre exemple 105k€) n’est plus viable : le Manager de Projet doit donc vraiment chercher d’autres fonds auprès du sponsor sinon le projet serait en danger.

Estimate to complete (ETC) [ETC=EAC-AC]: coût estimé nécessaire pour achever le travail qui reste à faire pour réaliser le projet. À un temps donné, il faut savoir combien cela peut coûter pour finir le projet à partir du moment où l’on effectue les mesures.

Avec notre exemple de déploiement d’une solution ToIP, le tableau cidessous montre les prévisions estimées à partir du mois 3 pour la fin du projet. Paramètre de mesures de prévisions BAC EAC ETC

Mois 5

105k€ 136,5k€ 71,5k€

On peut remarquer que le budget a

besoin de 31k€ supplémentaires par rapport au budget initial (BAC) pour réaliser le projet. Soit le Manager de Projet demande au sponsor de financer ce budget supplémentaire, soit il réduit le scope pour finir dans le budget.

Outils « Progresser en changeant ses points de vue. L’outil principal de l’homme est son cerveau ». Charles Péguy

Outils : élément t logiciel utilisé lor pour générer un p PMBoK®). Définition 31: Outils

Dans le management d’un projet, l’aspect relationnel est le plus important, les outils ne servant que de support au

manager du projet. Ce ne sera jamais l’inverse, aussi sophistiqué que soit l’outil. Les outils ne dictent pas l’approche en management de projet. Une organisation devrait toujours commencer par mettre en place une méthodologie de management de projet propre à ses types de projet, avant de se soucier des outils qui devront être adaptés à cette méthodologie. On peut automatiser les outils pour gagner en rapidité dans le management des activités et événements du projet. Mais il faut se souvenir que le succès ou l’échec dans l’utilisation de l’outil dépendra toujours de l’habilité de la

personne qui le manipule, ainsi que des processus et de la technique appropriés à l’application à laquelle ils sont destinés. Un idiot disposant d’un outil performant demeurera un idiot. Si l’objectif est d’enfoncer un clou dans un mur, un marteau représente l’outil idéal. Encore faut-il que la personne qui l’utilise sache manier le marteau et clouer proprement à l’endroit cible, cela sans plier le clou, et qu’elle comprenne bien le risque qu’elle court avec le marteau en tapant par exemple sur ses propres doigts. De même, on n’emploie pas un tank pour tuer une mouche. Un bon management de projet est une affaire de bon sens. On dit que le bon sens est

la chose la mieux partagée au monde, mais la connerie l’est aussi, comme s’armer d’outils disproportionnés par rapport aux objectifs à atteindre. Il faut s’équiper du minimum d’outils, car les manipuler prend du temps et engendre donc un coût supplémentaire à supporter sur les frais généraux du projet. C’est sans compter les heures de formations à donner aux managers de projets et à l’équipe projet amenée à utiliser ces outils. Une feuille de papier suffit selon OPPMI (One Page Project Manager), mais selon Vyew, il faut utiliser un outil visuel en ligne qui sert de salle de réunion virtuelle, surtout quand l’équipe est virtuelle.

« Un idiot disposant d’un outil performant demeurera un idiot. » Anonyme Enfin, on trouve sur le marché bon nombre d’outils automatisés pour le management de projets et de programmes qui, j’espère, seront un jour en « open source ». Le Manager de Projet a le choix entre faire acheter à son entreprise les outils du marché ou se contenter des outils disponibles au sein de son entreprise. Dénicher un outil qui convient à nos besoins peut être un processus complexe. Une fois qu’un outil est disponible, encore faut-il

pouvoir l’adapter à son projet. Les entreprises dotées de leurs propres méthodologies de projet auront développé en même temps leurs propres outils. Ces organisations ont souvent des bureaux de projets (PMO) qui génèrent des templates et améliorent constamment les outils à utiliser pour leur type de management de projet. Dans le cas contraire, le Manager de Projet, au sein d’une entreprise qui n’aura développé ni sa méthodologie de management de projet ni les outils appropriés, devra s’en remettre à luimême et faire preuve d’imagination dans la mise en place des outils adaptés à son projet, en plus de manager le projet.

Les outils le plus souvent utilisés le sont pour répondre aux besoins suivants : Planification et suivi des activités : une image valant mille mots, la plupart des outils disponibles disposent d’affichage graphique comme la charte Gantt par exemple, ainsi nommée après son inventeur Henry Gantt et datant du début des années 1900. On peut y trouver la liste et la séquence des activités, avec le début et la fin de chacune d’entre elles ainsi que le progrès réalisé pour chaque tâche.

Figure 71: Planification et suivi des activités (Diagramme de Gantt)

Tableau de bord : un Manager de Projet se sert de cet outil d’aide à la décision pour piloter son projet de façon proactive. Ce tableau de bord doit comprendre un certain nombre d’indicateurs de performance du

projet qui permettent de suivre l’état du projet et d’anticiper le futur en élaborant une stratégie à partir de ce tableau de bord. Le pilotage est basé sur la mesure permanente des dépenses réalisées par rapport aux prévisions initiales, toujours en rapportant, à une date donnée, l'effort financier accompli à l'avancement technique constaté. Chaque point de contrôle du projet devra permettre de faire une nouvelle estimation des coûts à fin dudit projet. Les indicateurs fondamentaux sont: 1. Suivi des délais/coûts: le Manager de Projet doit disposer

à une date donnée des informations suivantes: Le coût budgété du travail prévu (Planned Value) Le coût réel du travail effectué (Actual Cost) Le coût budgété du travail effectué (Earned Value) 2.

La visualisation de l'état du projet : ceci peut se faire à l'aide d'un diagramme de type GANTT comme on a vu plus haut, c’est au Manager de Projet de déterminer les indicateurs complémentaires du suivi de son projet. Ceci peut se faire par

exemple sur des thèmes tels que : la maîtrise des risques la qualité du projet les aspects sécurité Reporting : le Manager de Projet doit générer un certain nombre de rapports aussi bien sur l’état d’avancement que sur le bilan financier et le cash-flow du projet. Associé au tableau de bord et aux indicateurs de performance, le reporting donne une synthèse des informations pertinentes caractérisant l’état du projet. Il doit également, dans sa communication, faire un rapport régulier sur la performance du projet et les prévisions jusqu’à la

fin du projet. Le reporting répond à deux besoins : 1. pour le manager de projet, de connaître l'avancement des tâches au sein de son équipe, pour le prendre en compte dans son management du projet, 2. d’informer la hiérarchie de l'avancement du projet, des problèmes existants et des risques encouru. Tracking : le Manager de Projet doit réaliser un tracking des coûts, des dépenses ainsi que le temps passé par chaque ressource sur le projet.

Fichiers Log : le Manager de Projet doit disposer d’un outil pour capturer l’historique des demandes de changement, les risques et les problèmes survenus sur le projet, ainsi que les décisions prises au cours du projet. Collaboration en ligne des équipes virtuelles : comme nous l’avons vu dans le domaine de connaissance de management des ressources humaines, les équipes de projet sont de plus en plus souvent virtuelles, ce qui nécessite un outil permettant qu’elles collaborent

ensemble dans une salle de réunion virtuelle. Les médias sociaux sont de nos jours de plus en plus utilisés par les organisations qui sont rompues à la culture du management de projet. Il existe une pléthore d’outils pour répondre à chacun des besoins cités cidessus et chaque manager de projet aura ses préférences pour l’un ou l’autre, sauf lorsqu’ils sont imposés par l’organisation. Je n’imposerai pas d’outils dans cet ouvrage, je vous dirai simplement que les outils de management de projet doivent demeurer simples et faciles d’utilisation, les meilleurs s’avérant en effet être les moins sophistiqués.

Section 5 Encore des choses à connaître L’échec ou « y a-t-il une vie après la mort d’un projet » ? « Ce que l’homme a de plus authentique, c’est sa capacité à créer, se dominer, endurer,

se transformer, aimer et dépasser ses propres souffrances. » Ben Okri. Même si la vie continue après la mort d’un projet, cette dernière signe aussi la mort du Manager de Projet, du moins pour un temps. La guerre perdue menée dans les tranchées du management de projet peut être fatale aux développements de carrière d’un Manager de Projet. Un projet mort et qui n’a pu être secouru par l’intervention de l’équipe « search and rescue » est un projet qui n’a pas pu atteindre ses objectifs, qui a généré des surcoûts ou présente un retard irrécupérable. En résumé, je vais l’écrire ici noir sur

blanc : pour l’organisation, la responsabilité de l’échec échoit toujours au Manager de Projet, même si les circonstances et les conjonctures ne l’ont pas aidé et lui ont même été défavorables. Il faut savoir prendre ses responsabilités, mais cela ne veut pas dire tout assumer. Même quand le Manager de Projet fait son boulot correctement, un projet peut dégénérer à tout moment : manque de support de la steering committee à l’égard du projet et du Manager de Projet ; client qui arrête le projet pour raison financière ; offre initiale vendue à perte empêchant le Manager de Projet de livrer le projet dans les coûts budgétés ou pire encore,

ne permettant pas au projet d’offrir de retour sur investissement (ROI). Il suffit d’une petite cause pour que la situation dégénère en engendrant des effets dévastateurs et le Manager de Projet sera toujours associé au sort du projet. Si celui-ci dégénère, c’est le plan de carrière du Manager de Projet – du moins, dans cette organisation et si ses ambitions étaient de prendre la place du boss – qui risque de tomber à l’eau s’il ne prend pas le contrôle des choses immédiatement. Si vous travaillez pour ces organisations offrant une promotion aux managers dont les projets ont été un échec total, vous pouvez vous estimer heureux car, dans le cas contraire, il va

falloir ramer et se battre pour rétablir votre réputation et étouffer les rumeurs. Le Manager de Projet doit garder en tête que sa réputation décide de son destin. Si elle est bonne, son destin le sera aussi, si elle est mauvaise - et il suffit d’un projet raté pour qu’elle le devienne pour un temps -, le Manager de Projet devra nager à contre-courant au moins pendant un moment. Les malentendus et les rumeurs propagées sur soi sont autant d’obstacles pour se refaire une santé sur un autre projet.

Il n’y a rien de plus frustrant que de faire l’objet, un jour, de critiques parce que l’on n’a pas mené à bien un projet, de voir sa cote de popularité, si haute auparavant, s’effondrer alors que l’on s’apprêtait à se voir confier les projets les plus complexes et les plus ambitieux, d’être vouvoyé comme au premier jour et progressivement mis de côté. Puis un jour, plus rien. Plus d’équipe projet, plus de stakeholders, parfois plus d’amis, plus de coups de téléphone, ni d’e-mails, un grand vide et un grand moment de solitude : tous les projecteurs sont braqués vers le Manager de Projet, qu’on louait il y a encore quelque temps

pour ses qualités et que l’on considère à présent comme un perdant, ce qui ne fait qu’accentuer son mal-être et son sentiment de honte inspirés par l’échec. « La plus grande gloire n'est pas de ne jamais tomber, mais de se relever à chaque chute. » Confucius Dans certaines organisations, au mieux on confie à ces managers de projet déchus des projets sans risques et qui ne sont pas critiques pour le business, au pire, c’est la porte ou le placard. Dans d’autres, le développement de carrière en interne se base sur la règle des 50% de Robert Townsend, ce qui amènera

l’ancien Manager de Projet à être davantage affecté à des tâches sans challenges, risques ni complexités.

Règle de Robert Towns personne avec un profil poste, qui a un record de en six mois, cette person et tout le monde sera sat Loi 10: Règle de Robert Townsend sur les embauches pour un poste

Un Manager de Projet peut craquer « Impose ta chance. Serre ton bonheur et va vers ton risque. À te regarder, ils s’habitueront. » René Char, extrait des Matinaux

Dans certaines autres compagnies, on fonctionne au mépris, au déclassement, voire à la rancœur vis-àvis des managers de projet qui échouent. Je vous laisse imaginer les conséquences de votre échec sur un très grand projet de quelques millions à très forte visibilité qui ferait, pire encore, la une des presses spécialisées. Il faut se souvenir que le Manager de Projet est estimé selon le succès de son dernier projet. Nous vivons dans un monde marqué par le souci croissant de la compétitivité, l’exigence de la performance individuelle atteint parfois des proportions intenables. Elle peut générer également des échecs qui

dégradent souvent l’estime de soi et conduisent parfois les personnes à s’autodétruire car elles sont prises dans la spirale de l’échec. Le Manager de Projet doit néanmoins garder à l’esprit qu’il ne s’agit que d’un projet raté et ne pas le prendre personnellement : il faut éviter de s’enfoncer dans une déprime, de sombrer dans l’alcoolisme ou encore de se lancer dans des violences conjugales histoire d’équilibrer l’estime perdue au boulot. L’existence se charge de nous construire tels que nous sommes ; mais c’est parfois au prix de sévères désillusions.

Conséquences d’un échec: s’enfoncer ou rebondir

Les échecs ne sont pas sans conséquences, le rêve d’accomplissement professionnel peut en être transformé à jamais, mais si on déborde toujours d’enthousiasme et que l’on aspire toujours à une belle réussite dans le management de projet ou un autre métier, c’est l’esprit qu’il faut avoir : ceux qui ont perdu gros ont gagné gros aussi plus tard, on peut toujours rebondir, dans la même organisation ou ailleurs, en faisant preuve de détermination, voire d’acharnement sur un prochain projet. Une petite victoire sur un petit projet peut relancer le goût pour le dépassement de soi et de la valeur de l’effort que l’on a pu perdre

avec l’échec du projet précédent. Un bon Manager de Projet doit savoir puiser dans sa résilience, sa réserve pour aller de l’avant plus que jamais. Cela s’avérera difficile, le Manager de Projet aura l’impression de ne prendre que de mauvaises décisions sur son prochain projet et chaque personne qu’il croisera se permettra de lui faire des remarques moralisatrices et arrogantes sans même prendre la peine de considérer la situation. Mais il en est heureusement qui s’abstiendront d’émettre des jugements, car ils savent que ceux qui tentent courent le risque de faire des erreurs, ils savent combien il est difficile de se retrouver au milieu de

l’arène et vous apprécierez particulièrement ces personnes-là pour leur intégrité morale. Elles ne confondent pas droiture et rigidité. Au risque de me répéter, j’insiste sur le fait que vous puissiez développer ce concept de résilience, cette capacité de rebondir dans les moments critiques marqués par l’échec et que si vous n’avez pas le tempérament, il faut rendre tout simplement votre tablier de Manager de Projet. Il faut pouvoir tirer les leçons du passé et aller de l’avant : l’erreur est de s’acharner à ressasser et évoquer un événement qui a eu lieu et auquel on ne peut plus rien changer. L’expression

« parler pour ne rien dire » n’a jamais paru plus pertinente que dans ces moments où l’on ressasse le passé en refaisant le monde, en se repassant le projet à l’esprit… À petite dose, cela prouve beaucoup d’affection, mais à forte dose, c’est de la faiblesse d’esprit, disait William Shakespeare. Les cicatrices de nos échecs nous rappellent ce que l’on a traversé dans le passé, mais cela ne devrait pas dicter notre futur, on peut refaire son monde sur le prochain projet.

De la résilience avant toute chose On peut puiser cette résilience dans la sagesse, l’expérience et la perspective.

L’expérience est le nom que chacun donne à ses erreurs, disait Oscar Wilde et le sens des perspectives est ce qui différencie un Manager de Projet quelconque d’un autre plus mature : ce dernier pense qu’il y aura toujours des jours meilleurs, que ce qui ne l’abat pas ici le rendra plus fort. Garder le goût et la joie de vivre, même à travers les difficultés les plus crues, ne signifie pas nier ni refouler les problèmes. Il faut les affronter en gardant la tête haute et en faisant preuve de présence, et surtout ne pas confondre s’effacer et faire profil bas. Un jour, certes, nous nous sommes montré moins performant mais il ne faut pas perdre de vue la perspective que

demain est une chance pour s’essayer à nouveau sur un autre projet. Un dicton ne dit-il pas que chaque échec est la promesse d’une réussite à venir ? « La flexibilité est une qualité cardinale pour demain. Si je m’oriente dans un sens et que je me heurte à un mur, je dois être suffisamment flexible pour changer de chemin, de métier, de projet ou d’idée ». Jean-Marie Messier, extrait de Le jour où le ciel nous est tombé sur la tête.

S’ouvrir à d’autres métiers : une progression latérale

Si cela ne marche plus dans le management de projet, il faut se montrer flexible dans sa carrière et changer de métier, car une vie professionnelle est jalonnée de plusieurs métiers, tout comme la vie personnelle n’est qu’une succession de fins et de nouveaux départs. Je ne vous encourage pas ici à changer de mari ou de femme et d’enfants quand cela vous arrange. Je vous suggère juste que l’on peut repartir de zéro : si vous ne vous épanouissez pas dans le management de projet, pensez à une évolution latérale. Le temps où l’on faisait 40 ans de carrière dans la même boîte est révolu. Il faut pouvoir cultiver le goût des vies

multiples, parallèles, voire même contradictoires, non seulement en termes de carrières mais dans la vie en général. Jacques Attali, dans Une brève histoire de l’avenir, affirme que d’ici à 2025, plus de la moitié des travailleurs changeront de résidence tous les cinq ans et plus souvent encore d’employeur. Il ne faut pas hésiter à aller chercher ce qu’on veut là où on peut le trouver, toujours est-il qu’il faut savoir ce que l’on veut et en trouver le chemin.

Carrière d’un Manager de Projet « On crée son propre univers à mesure qu’on avance ». Winston Churchill

Quand on vient de finir un projet, que celui-ci ait été un succès ou un échec, la question de notre développement personnel nous taraude constamment et se pose naturellement. Chacun de nous est tôt ou tard amené à revoir la définition de sa vie, ses priorités et à en travailler le sens. Le pire, c’est l’absence de chemin. On veut d’une vie nouvelle sans perdre l’ancienne alors que pour chaque choix, on sait toujours ce qu’on perd et on ne sait jamais ce qu’on gagne. Et on a tous en commun l’envie de réussir quel que soit le choix fait. On tend tous vers le sommet, l’amélioration ou encore la réalisation de soi si l’on en croit la pyramide de Maslow. Mais comme le dit Blaise

Cendrars, c’est dans ce qu’on a le plus en commun que l’on se différencie le plus, et à juste titre, chacun a son style d’existence, chacun a ses goûts, ses priorités, sa propre définition de la réussite - réussir dans la vie ou réussir sa vie ; mais il faut admettre que réussir sa vie exige de se débarrasser de l’idée de la réussite qui nous a été inculquée et de trouver ce pourquoi on a envie de vivre, pour quel métier. Cela passe par la découverte de soi, de ce que l’on veut profondément. Daniel Balavoine chantait haut et fort que la vie ne lui apprenait rien. A-t-il eu tort ou raison ? Je n’en sais rien, mais je sais que la vie sur un projet, que celui-ci soit raté ou réussi, est une expérience

riche d’enseignement sur soi, sur nos capacités de résilience et résistance, sur nos limites, sur ce que l’on veut ou peut faire plus tard et ce que l’on ne veut pas ou ne pourra plus faire plus tard. Le savoir-faire acquis dans la douleur, par un dur labeur, forge le Manager de Projet et peut l’aider sur les projets à venir. Seul un travail acharné, et tous les managers de projets savent de quoi je parle, augmente la chance de réussir, mais il ne faut pas pour autant oublier de travailler dans la joie, même si on traverse des moments désagréables ; car si l’on voit le métier de management de projet se transformer en corvée et qu’on a l’impression de devoir se forcer, on va

tout droit à l’échec. Un Manager de Projet qui ne prend pas plaisir à manager son projet augmente son risque d’échec. Même si certains jours défilent très vite et qu’on est en apnée pendant un moment sur le projet, on a toujours le temps, en se rasant le matin, en se démaquillant le soir, de s’interroger sur l’intérêt qui nous pousse à faire ce que l’on fait, sur les plaisirs qu’on en tire et surtout, sur l’envie de poursuivre dans ce domaine ou pas.

Figure 72: Quel développement de carrière pour un Manager de Projet?

Si on en a plus qu’assez du management de projet, frustré, écœuré, ce n’est plus la peine de poursuivre dans cette voie.

Mais, au contraire, si on reconnaît qu’à côté des moments ennuyeux, éreintants, on a tout de même vécu des instants merveilleux et spectaculaires sur le management d’un projet, totalement stimulants, éprouvants et percutants à la fois alors, il faut persévérer dans cette voie car c’est une expérience qui mérite d’être poursuivie ; recenser ses mérites, et ses fautes ; essayer, en fonctions des résultats, de corriger le tir. Pour continuer, le Manager de Projet remet sa crédibilité et sa réputation en jeu sur le prochain projet qu’il va manager et ne peut pas se permettre de se reposer sur ses lauriers car, on l’a vu plus tôt, une organisation a la mémoire courte. Quel

que soit le niveau que l’on a atteint, désirons toujours plus, posons-nous toujours la question du what next, à savoir qu’on est dans une course sans fin vers l’étape suivante. On dit qu’une personne qui aspire au même travail toute sa vie peut présenter des déficiences intellectuelles. « Savoir où vous voulez aller, qui vous voulez devenir, c’est votre meilleur atout. Sans but, il est difficile de marquer des points. » Paul Arden Le développement de carrière d’un Manager de Projet dépend de l’industrie et de la compagnie pour laquelle il

travaille mais, de façon générale, on peut imaginer une trajectoire de carrière de Manager de Projet comme suit : 1. Manager de Projet junior : on le devient au gré des circonstances de l’organisation. Peut-être qu’un jour, il existera des écoles qui ne formeront que des managers projets et l’on recrutera le jeune diplômé à la sortie de l’école comme Manager de Projet junior, à faire bien sûr encadrer par un senior, même si la plupart du temps on l’affecte sur des projets sans risque à faible budget. 2. Manager de Projet: l’organisation peut confier à ce genre d’individu un

projet dans la limite de certains budgets et de niveau de risque médium. On lui demande de passer les certifications nécessaires pour se voir confirmé comme professionnel du management de projet. 3. Manager de Projet senior : l’organisation peut confier à ce genre d’individu les projets à haut risque et à grand budget. Il est bien sûr certifié professionnel du management de projet. Ce genre de Manager de Projet fait partie de l’escouade ou de la SWAT Team des managers de projet et peut se voir confier des missions de « search & rescue », à

savoir, le sauvetage, la remise sur le bon chemin des projets en péril qui ont perdu tout repère ou direction stratégique, ou qui font du sur place. Ce genre de manager peut également se faire une spécialité de « killer » des projets non rentables dans les termes du contrat mais avec un minimum de dépenses car ces projets ne peuvent plus atteindre un ROI positif. Bien sûr, il peut servir de mentor et coacher les managers de projet junior. 4. Manager de programme : l’organisation peut confier à ce genre d’individu le management d’un programme, qui n’est autre qu’une

addition de projets interdépendants, managés chacun par un Manager de Projet et dont la réussite ou l’échec influe sur les objectifs du programme (voir section 2). 5. Manager du PMO (bureaux des projets) : l’organisation peut confier le management des activités du PMO dans l’organisation. Chaque PMO aujourd’hui est différent d’une entreprise à l’autre, mais dans cet exemple, on peut dire que le PMO est responsable de la priorisation des lancements de projet et de la méthodologie de management de projet, y compris le développement

d’outils, de techniques et de templates standards à utiliser sur tous les projets. 6. Manager de portfolio : l’organisation peut confier à ce genre d’individu le management d’un portfolio, qui est composé de projets et de programmes interdépendants dont les objectifs s’alignent clairement avec les objectifs stratégiques de l’organisation fixés par ses leaders. 7. Vice-Président (VP) ou CEO (Chief Executive Officer) : les arbres de progression de carrière ne

montent pas jusqu’au ciel, mais ce niveau de progression est réaliste et envisageable. On peut en rire, mais il faut savoir que l’ambition ou l’envie démesurée fabriquent aussi les réussites et les victoires. Jack Welsh, pour ne citer que lui, l’a fait. On peut débattre du système de l’élite en France qui consiste à penser que l’on n’a pas fait de brillantes études si l’on ne sort pas des grandes écoles et certes, ces positions de VP ou CEO sont réservées à ces élites, mais on peut aussi rentrer par la petite porte avant de devenir VP ou CEO en passant par les compagnies qui ne fonctionnent pas aux diplômes mais

aux mérites. En tout cas, il faut essayer d’échapper au déterminisme, il faut se montrer capable de vivre en s’écartant de son origine, de penser de façon latérale, sans avoir peur de se rapprocher de ce qu’on désire profondément même si, au départ, on n’était pas prédestiné à ce genre de fonctions. « La lutte elle-même vers les sommets suffit à remplir un cœur d’homme. Il faut imaginer Sisyphe heureux. » Albert Camus Plus on avance dans la vie, plus nos idées évoluent et changent, ce qui nous convient maintenant peut ne plus nous convenir dans le futur, je ne crois pas

que l’on puisse indéfiniment suivre des itinéraires verticaux et tout tracés. Les gens font davantage preuve de flexibilité et de développement latéral. Certaines compagnies repèrent ces personnes qui ont apporté de la valeur dans un domaine et font tout pour les affecter ailleurs afin d’éviter qu’elles ne s’ennuient et qu’elles puissent apporter d’autres valeurs dans un autre environnement où les défis ne manquent pas. Il faut sans cesse se poser la question de ce qu’on veut être dans cinq, dix ou quinze ans, et tout faire dès lors pour se diriger dans cette direction. Personne d’autre que vous ne crée votre expérience, c’est vous qui en êtes

entièrement responsable ; ce que l’on sème aujourd’hui, on le récoltera demain. Comme le disait Abraham Lincoln, ce qu’il y a de bien avec le futur, c’est qu’il n’arrive pas d’un seul coup, il se prépare.

Le capital humain (mes aptitudes) vs capital social (mes relations) « Tous nos actes sont provoqués par deux désirs fondamentaux : le désir sexuel et le désir d’être reconnu. » Sigmund Freud Comme déjà mentionné à maintes reprises, le relationnel est l’aspect le

plus important dans le management de projet car souvenons-nous de l’adage « ce qui important n’est pas ce que vous savez faire, mais qui vous connaissez ». On pense toujours à cet adage lorsqu’on assiste à la promotion d’une personne moins qualifiée que soi. Il ne faut pas chercher loin, cette personne a été promue non pas sur base de ses compétences mais parce qu’elle a su tisser les bonnes relations. Un Manager de Projet déchu peut également se vendre à sa hiérarchie et à son organisation en se jouant de ses relations et de montrer qu’il a toujours les caractéristiques qui font de lui ou d’elle l’homme ou la femme pour manager un

projet. On s’est tous déjà demandé comment une personne a pu être nommée à un poste après l’échec de ses précédentes missions. Cette personne a su tout simplement mieux se vendre en se jouant de ses relations. Le capital humain (le savoir-faire et compétences) ainsi que le capital social (les relations) contribuent dans la productivité du Manager de Projet, mais dans certaines organisations plus qu’ailleurs, le capital social a plus d’impact sur la productivité et, bien sûr, sur le développement de la carrière du Manager de Projet. Manager un projet est l’opportunité de se construire une crédibilité et

également, de se constituer un réseau de relations dont on vient de voir l’importance et l’impact aussi bien sur le projet que sur la carrière professionnelle. Comme je l’ai mentionné dans mon premier ouvrage, Le Monde des Sociétés de Service (éd. Bénévent), les réseaux ont l’avantage d’élargir notre monde, d’ouvrir des portes, de nous offrir un champ d’action sociale, sans structure peut-être mais plus large. Cela permet de repousser certaines limites, de toucher des personnes haut placées, d’obtenir des choses qu’on n’obtiendrait jamais tout seul.

Le succès ou comment on

devient grand « Le succès n’est pas la clé du bonheur. Le bonheur est la clé du succès. Si vous aimez ce que vous faites, vous réussirez ». Albert Schweitzer Vous venez de boucler le projet avec succès, vous allouez les ressources comme un chef, vous êtes un as des plannings, vous avez su bouger des montagnes d’obstacles, vous avez su calmer les nerfs des stakeholders, vous avez livré le projet dans les délais et budgets impartis avec la qualité requise, le retour sur investissement de votre projet est en ligne avec les ambitions du

business et pour couronner le tout, votre projet a eu un grand impact socioéconomique pour la société. Savourez donc ces moments, ces vagues d’euphorie car vous allez devoir remettre en jeu votre réputation sur le prochain projet. Vous pouvez en tirer une immense plus-value et en profiter pour demander à manager un projet encore plus complexe que le précédent ou une promotion dans votre organisation ou ailleurs, assortie bien sûr d’une augmentation de salaire. Il est bon également d’aller voir ailleurs quand votre organisation n’offre pas les challenges que vous souhaitez. Un bon Manager de Projet, surtout à succès, ne

se complaît pas dans le laisser-aller, il s’épanouit dans l’exigence de soi, se concentre sur la réussite de la mise en œuvre de ses compétences et ne se sent heureux qu’en relevant à chaque fois de nouveaux défis, s’occupant de missions critiques et complexes que tout le monde pensait infaisables jusque là. Il rendra tout simplement son tablier dans l’absence de challenges ou s’il sent qu’il ne se développe plus au sein de la même organisation. Il est constamment en compétition avec lui-même. Il est plus facile pour un indépendant (freelance) d’aller voir si l’herbe est plus verte ailleurs et de quérir un meilleur client, non pas une vache à lait, mais un client

offrant les challenges qui correspondent à ses aspirations professionnelles, car ce n’est pas toujours une question d’argent mais bien d’épanouissement personnel. Il faut savoir qu’un Manager de Projet qui vient de réussir son projet a une très bonne réputation et peut démarcher, voire choisir son prochain projet, offrant davantage de challenge comme de risque, de budget, de complexité. On peut s’assurer à chaque succès de le faire graduellement. Certains disent qu’on a la carrière que l’on mérite en choisissant ses projets, ou encore en choisissant de quitter un navire sur le point de couler. Les cimetières sont remplis de héros. Les

organigrammes des dirigeants d’entreprises sont remplis de lâches pour ne pas arrêter les projets qui coulent, surtout ne coulez pas votre carrière avec, car comme on a vu plus haut, il s’agit là également de votre réputation, alors allez voir ailleurs si vous y êtes.

La fin où tout commence « Quoi que tu rêves d’entreprendre, commence-le. L’audace a du génie, du pouvoir, de la magie. » Johan Wolfgang von Goethe Les sections précédentes permettent de poser le cadre essentiel pour manager efficacement un projet d’envergure

internationale. Elles ont mis en lumière le management de projet à travers des exemples et donné un aperçu des différentes facettes de la vie d’un Manager de Projet. Le management de papa est passé de mode et il faut désormais passer par les méthodologies de standard international. Nous avons vu les sens, l’essence et les raisons d’être des projets, nous avons démontré pourquoi il est capital, pour le business d’une organisation, d’adopter une méthodologie et des vocabulaires communs pour livrer ces projets. Enfin, nous avons abordé les compétences, les domaines de connaissances, les processus, les outils et les techniques pour un management efficace des

projets. Cet ouvrage consistait à montrer comment on peut appliquer ces « bonnes pratiques » dans sa vie de Manager de Projet au quotidien, à travers des exemples concrets facilement transposables sur un projet. J’espère vous avoir interpellé et inspiré, au fil du texte, quant à la pratique du management de projet dans votre quotidien. J’espère aussi avoir suscité en vous l’envie de devenir Manager de Projet. « Il n’y a pas de formule magique pour réussir hormis, peut-être, une acceptation inconditionnelle de la vie et de ce qu’elle apporte ». Arthur Rubinstein Une vie réussie n’est autre qu’une vie menée selon nos souhaits, en agissant

toujours conformément à nos valeurs, en donnant le meilleur de soi dans ce que l’on entreprend, en demeurant en harmonie avec qui l’on est et, si possible, une vie qui nous permet de nous dépasser. Je sais que cet ouvrage n’aura pas l’impact de ce qu’ont pu laisser au monde du management de projet Henry Fayol vers la fin du XIXe ou, au début du XXe s., Henry Laurence Gantt, dont le diagramme est toujours aussi présent dans le quotidien d’un Manager de Projet. Tout ce que je sais, c’est qu’au XXIe s., la demande en compétence de management de projet ne fait que s’accroître car les organisations ont

réalisé que les projets sont véritablement les outils de leur croissance. Manager de Projet est un métier d’avenir. J’espère que cet ouvrage vous aura éclairé quelque peu sur les façons d’appliquer les méthodologies de standard international à vos projets ou incité à devenir Manager de Projet et de persévérer dans cette voie. Harley Lovegrove a terminé son discours sur le management de projet, au dernier congrès de PMI® Benelux en 2009, en déclarant que le management de projet est plus que le meilleur métier du monde, c’est une façon de vivre. C’est une profession dévoreuse de

temps, qui ne s’arrête jamais, mais pour ceux qui sont passionnés, elle procure plaisir et épanouissement. Quand on vient de livrer un projet, lorsque l’adrénaline commence à redescendre juste après l’accélération finale, à cet instant même, on peut ressentir une euphorie naturelle, un état qui nous rend léger et qui correspond tout simplement à de la joie de vivre, la sensation sublime d’avoir accompli sa mission. Je souhaite à tout Manager de Projet de vivre et d’éprouver la même chose.

Table des matières SECTION I Parlons plutôt du Management de Projet Les raisons d’être de cet ouvrage Evolution du management de projet Le composant culturel Vocabulaire du management de projet De la méthodologie à la pratique À qui cet ouvrage s’adresse-t-il ? Pourquoi le CEO (Chief Executive Officer) ou Président-Directeur Général (PDG), les vice-présidents (VP) et autres directeurs d’une organisation devraient-ils lire cet ouvrage ?

Pourquoi les professionnels désireux de devenir managers de projet devraient-ils lire cet ouvrage ? Pourquoi les étudiants devraient-ils lire cet ouvrage ? Pourquoi les formateurs en management de projet devraient-ils lire cet ouvrage ? Pourquoi les managers de projet, préparant leurs certifications PMP® devraient-ils lire cet ouvrage ? Pourquoi une certification en PMP® est-elle utile ? Pourquoi les managers de projets confirmés, détenteurs de leur certification PMP® ou de celle d’une autre organisation, voudraient-ils lire

cet ouvrage ? Pourquoi ceux qui souhaitent développer leurs carrières dans le management de projet devraient-ils lire cet ouvrage ? Un ouvrage tiré de faits divers et des expériences des autres La structure de l’ouvrage Caractéristique de l’ouvrage SECTION 2 Essence et Sens des Projets Patchwork - Un tour ensemble (potpourri) sur les idées reçues concernant les projets Un projet est avant tout du Business avec un retour sur investissement (ROI) positif

Qu’est-ce qu’un projet réussi? Succès mesuré à partir de la valeur créée pour le Business Succès mesuré à partir de la satisfaction du client Un projet avec un bon impact économique, social ou environnemental Pyramide du succès d’un projet à cinq niveaux Statistiques sur les succès des projets de 2000 à 2009 Si les projets peuvent être classifiés par tailles, comment déterminer cellesci? Typologie de projet par le budget Comité de pilotage pour un projet

Large ou Extra Large Typologie de projet par l’effort Typologie par heure et par revenu Le projet et la triple, voire la quadruple contrainte Objectifs S.M.A.R.T. des projets Un projet possède des stakeholders (parties prenantes) Les attentes des stakeholders et ce qu’on attend d’eux en relation avec le projet Technique d’analyse des stakeholders Un projet a des hauts et des bas, des temps forts et des temps faibles Définition d’un projet Un projet crée un produit, un service

ou un résultat unique Un projet est un effort temporaire Un projet n’est pas une opération Un projet a un début déterminé Charte de Projet Genèse d’un projet Phase 1 : Besoin de projets et leur finalité Identification d’un projet Phase 2 : Sélection des projets par Business Case Un projet présente une fin déterminée lorsque ses objectifs sont satisfaits Un projet a une fin déterminée lorsque les objectifs du projet ne sont plus

atteints ou ne sont plus jugés utiles Les facteurs d’échec d’un projet La traversée du désert du Manager de Projet Un projet peut faire partie d’un programme ou d’un portfolio Portfolio Programmes Projets Un projet a un cycle de vie constitué de plusieurs phases Un projet peut être managé par phase et par étape La porte d’étape (stage gate) Section 3 Besoin de Méthodologie Pourquoi ce besoin d’adopter une

méthodologie standard ? Les organisations standardisent leurs méthodologies Une méthodologie à l’image de l’organisation La justification d’une méthodologie Une méthodologie et un vocabulaire commun Meilleure intégration de la méthodologie à travers les PMOs Le chapitre de PMI® et l’importance des réseaux de Manager de Projets Section 4 Le Management de Projet Le management de projet en général Périmètres et Facteurs environnementaux

La culture Le management de projet est l’application des connaissances La dimension Business Management de l’intégration du projet Elaborer la charte du projet Le point de départ de tout projet Pourquoi ne faut-il jamais commencer un projet sans Charte de Projet signée ? Soulignons encore une fois l’importance de la signature de la charte de projet Contenu de la charte de projet Compétences clés pour l’écriture de la charte de projet: négociation, communication

Élaborer le plan de management du projet Diriger et piloter l’exécution d’un projet Processus – Suivre et maîtriser le travail du projet Mettre en œuvre la maîtrise intégrée des changements de scope Clore le projet Management du scope du projet Recueillir les exigences ou la voix du client Définir le scope Impact d’une mauvaise définition du scope Créer un WBS

Vérifier le scope Contrôler le scope Management du Délai du projet Définir les activités Organiser les activités en séquence Estimer les ressources nécessaires aux activités Estimer la durée des activités Élaborer l’échéancier du projet Maîtriser l’échéancier Management du coût du projet Estimer les coûts - ROM (Rough Order of Magnitude) Facteurs à prendre en compte dans l’estimation des coûts Déterminer le budget

Maîtriser les coûts Contrôle des coûts Performance du projet en termes de coûts Mesures de Prévision en termes de budget Management de la qualité du projet Les coûts de la qualité (Cost of Quality – COQ) Planifier la qualité Mettre en œuvre l’assurance qualité Mettre en œuvre le contrôle qualité Management des Ressources Humaines du projet Qui sont ces ressources humaines ? Ressources virtuelles et multilingues

Ressources « Normales » vs « Virtuelles » Management plus complexe des ressources virtuelles Elaborer le plan de ressources humaines Constituer l’équipe de projet Ressource Interne Ressource Externe Développer l’équipe de projet Diriger l’équipe de projet Manager les ressources en fonction du planning Manager la motivation de l’équipe et l’effet d’accélération finale Manager les conflits avec les

ressources toxiques Approche pour résoudre les conflits Management des réunions avec les ressources Communication verbale et paraverbale Quelques règles de base pour une réunion réussie Évaluer la performance de son équipe Manager la notion de plaisir sur un projet Management des Communications du projet Identifier les stakeholders ou parties prenantes Planifier les communications

Diffuser les informations Manager les attentes ou exigences des stakeholders Rendre compte de la performance Management des Risques du projet Planifier le Management des Risques Identifier les Risques Les différents types de checklist Mettre en œuvre l’analyse qualitative des risques Analyse de niveau des risques par la probabilité et l’impact Analyse de niveau des risques par le score et l’impact Mettre en œuvre l’analyse quantitative des risques

Méthode des Trois Points (Minimum, Probable, Maximum) La simulation Monte-Carlo Planifier les réponses aux risques Seuil et critère de risques Réponses aux risques qui menacent le projet Surveiller et maîtriser les risques Management des Approvisionnements du projet Planifier les approvisionnements Procéder aux approvisionnements RFP, RFT, RFQ, RFI, etc. Évaluation d’appel d’offres ou d’appel à propositions Le contrat entre le client et le

fournisseur Contrat à coûts remboursables : CPF, CPAF, CPIF, etc. Contrat à prix fixe : FFP, FPIF, PTA Comparaison des risques entre contrat à coûts remboursables et contrat à prix fixe Manager les approvisionnements Clore les approvisionnements L’application de connaissances nécessite le management efficace de processus appropriés Groupe de processus de Démarrage (2 processus) Groupe de processus de Planification (20 processus) Groupe de processus d’Exécution (8

processus) Groupe de processus de Contrôle et de Surveillance (10 processus) Groupe de processus de clôture (2 processus) Elaboration sur mesure Les phases de projet ne sont pas les groupes de processus de management Le management de projet est l’application de compétences Performance en Management de projet Un sens du leadership Un leader proactif Un leader avec une vision Apprendre à être leader en faisant Un leader disponible

Un leader avec de l’assurance personnelle Un leader synergique Un leader par l’exemple Un leader avec de l’influence Un leader qui inspire Un sens aigu du détail Historicité du projet et connaissance de l’équipe Intelligence relationnelle Passion et foi dans le projet Enthousiasme, congruence et résilience Les théories X et Y Capacité de prendre des décisions Causes d’erreurs les plus courantes dans la prise de décisions

Les différentes façons de prendre des décisions Une bonne communication et un sens aigu de la relation humaine Pourquoi une bonne communication est-elle importante? Les super-sympas, les je-sais-tout, les frimeurs et grincheux etc Qu’est ce qu’une bonne communication ? Communication non violente (CNV) Possession d’une maturité émotionnelle Les moments éprouvants émotionnellement sur un projet Être mature émotionnellement La force de la maturité émotionnelle

Compétences managériales La cohésion de l’équipe avant toute chose Coordonner et diriger avec autorité et charme Un environnement coopératif agréable et un climat de confiance Le dépassement par la performance collective Responsable, intègre et honnête Respect Honnêteté Intégrité Responsabilité Un sens de l’éthique irréprochable Le management de projet est

l’application d’Outils et de Techniques Technique Technique de collecte d’information et d’aide à la prise décision Jugement d’Expert Brainstorming Technique Delphi Technique de développement du planning PERT Déviation Standard Technique des 3 Points Élaboration progressive PDM (Precedence Diagramming Method) ou méthode des antécédents Décalage avec Avance (Lead) –

Décalage avec Retard (Lag) Chemin critique Les contraintes temporelles et de ressources Planification par vague (Rolling Waves) Fast Tracking - Exécution accélérée par chevauchement Crashing – Compression des délais La méthode de la chaîne critique Technique de Mesure de Performance et de Prévision Technique de la Valeur Acquise ou Earned Value (EV) Mesure de Prévisions en termes de délai et de budget

Outils Section 5 Encore des choses à connaître L’échec ou « y a-t-il une vie après la mort d’un projet » ? Un Manager de Projet peut craquer Conséquences d’un échec: s’enfoncer ou rebondir De la résilience avant toute chose S’ouvrir à d’autres métiers : une progression latérale Carrière d’un Manager de Projet Le capital humain (mes aptitudes) vs capital social (mes relations) Le succès ou comment on devient grand La fin où tout commence

Table des Lois et Règles Table des Definitions Table des Figures

Exemple 1: Organisation fonctionnelle par projet et équipes éparpillées dans le monde Exemple 2: Problème mal défini Exemple 3: Projet qui vise un changement économique et social Exemple 4: Projet avec durée et budget Exemple 5: ROI positif Exemple 6: Projet avec retard et au-delà du budget pouvant rencontrer un ROI positif Exemple 7: projet à satisfaction du client Exemple 8: Méthodologie pour améliorer la satisfaction du client Exemple 9: Projet à succès avec un

impact social, économique ou environnemental Exemple 10: Template pour capturer les leçons apprises sur un projet Exemple 11: Typologie de projet classifié par budget Exemple 12: Processus de fonctionnement du Comité de Pilotage Exemple 13: Typologie de projet classifié par l'effort Exemple 14: Typologie de projet classifié par nombre d'heures et de revenus Exemple 15: Enoncé des objectifs d'un projet en suivant la méthodologie SMART Exemple 16: Stakeholders par catégorie

Exemple 17: Identification de Stakeholders sur un projet Exemple 18: Attente conflictuelle des stakeholders sur un projet Exemple 19: Analyse et mapping des attentes des stakeholders du projet Exemple 20: Analyse et mapping des attentes des stakeholders du projet (suite) Exemple 21: Technique d'analyse des Stakeholders Exemple 22: Projet qui crée un résultat unique Exemple 23: un projet qui crée un service unique Exemple 24: Un projet qui crée un produit unique

Exemple 25 : Opération : un projet n’est pas une opération Exemple 26 : Contenu de la Charte de Projet Exemple 27 : Sujets à aborder pendant la réunion de kick-off Exemple 28 : Projets lancés suite à la demande du marché Exemple 29: Demande du marché de projet écologique – WADI RUM Exemple 30: Demande du marché de projet écologique - General Electric Ecomagination Exemple 31 : Projet lancé suite à une opportunité stratégique ou de besoin d’affaires Exemple 32 : Projets lancés suite à une

demande du client Exemple 33 : Projets lancés suite à l'innovation ou aux avancées technologiques Exemple 34 : Projets lancés suite aux obligations légales Exemple 35 : Projets arrêtés en cours de route Exemple 36:Portfolio de projets et de programmes Exemple 37 : Un portfolio de programmes et de projets Exemple 38: Portfolio Exemple 39 : Programmes issus du Portfolio V2D Exemple 40 : Projets issus de portfolios ou de programmes

Exemple 41 : Différentes durées de phases sur différents projets Exemple 42 : Porte d’étape vs phase Exemple 43 : Même projet mené par deux personnes aux méthodologies distinctes Exemple 44 : Projet réussi grâce à l’application efficace d’une méthodologie Exemple 45: Facteur Environnemental Exemple 46: Environnement et périmètres d’un projet à tenir en compte Exemple 47: Plan de Management d'un projet de ToIP Exemple 48 : Échéancier (planning) du projet ToIP Exemple 49: checklist pour passer d'une

phase à une autre Exemple 50 : Problèmes Log Exemple 51 : Risques Log Exemple 52 : Formulaire de Demande de changement Exemple 53 : Énoncé du scope du projet ToIP Exemple 54: WBS du projet ToIP Exemple 55 : WBS Dictionnaire Exemple 56 : Vérification du scope Exemple 57 : Liste des Milestones Exemple 58 : Liste des activités du projet ToIP Exemple 59 : Organiser les activités en séquence : Diagramme de Réseau Exemple 60 : Lead ou Avance Exemple 61 : Lag ou Retard

Exemple 62 : Organiser les activités en séquences sur MS Project Exemple 63 : Estimation des durées des activités d'un projet Exemple 64 : Contrôle et suivi des échéanciers (planning) Exemple 65: Plan de Management des coûts du projet ToIP Exemple 66: Estimation de coût à partir du WBS avec Compte de Contrôle Exemple 67: Budget du projet ToIP Exemple 68: Livrables Obligatoires et Points de Contrôle Exemple 69: Assurance Qualité Matrice de responsabilité Exemple 70: Assurance Qualité – Checklist par porte d’étape

Exemple 71: Signature et accord sur le Plan de Contrôle du Projet (PCP) Exemple 72 : Plan de Management des Ressources Humaines Exemple 73 : Charte de motivation d’une équipe Exemple 74 : Règle de base de management de conflits Exemple 75 : Guide et Procédure de réunion Exemple 76: Interface d'un Manager de Projet Exemple 77: Identification de Stakeholders Exemple 78: Canaux de communication Exemple 79: Fréquence de communication sur un projet

Exemple 80: Diffusion de la communication Exemple 81: Rapport - Bilan de santé générale du projet Exemple 82: Rapport - Bilan de l’échéancier du projet Exemple 83: Rapport sur le budget du projet Exemple 84: Plan de Management des Risques Exemple 85 : Définition d'impact des risques Exemple 86 : Définition des probabilités des risques Exemple 87 : Matrice d'évaluation des risques Exemple 88 : Évaluation par catégorie

des risques en fonction de l’impact et du score Exemple 89: Spectre des niveaux de risques par catégorie Exemple 90 : Analyse quantitative des risques – Méthode des Trois Points Exemple 91 : Mitigation des risques quand la date de fin d’un projet est imposée Exemple 92 : Approvisionnement Appel d'offres international Exemple 93 : Approvisionnement Appel à propositions Exemple 94 : Procéder aux approvisionnements Exemple 95: Evaluation d'appel à propositions pour organiser une Coupe

du Monde Exemple 96 : Contrat à coûts remboursables avec honoraire fixe (CPF) Exemple 97: Contrat à coûts remboursables avec intéressement Exemple 98: Contrat à prix fixe avec intéressement Exemple 99 : le fournisseur intervient durant la phase de design et d'implémentation du client Exemple 100: Phases vs Groupes de processus – customisation d’une méthodologie Exemple 101: Sens aigu du moindre détail Exemple 102: Théories X et Y

Exemple 103: Arbre de décision Exemple 104: Brainstorming Identification des risques Exemple 105 : Estimation de la durée des activités avec les techniques PERT, 3 Points et Exemple 106 : Lead et Lag sur un planning Exemple 107 : Diagramme des antécédents avec des contraintes Exemple 108 : Crash du planning Exemple 109 : Résultat après crash du planning Exemple 110 : Valeur Planifiée (PV) Exemple 111 : Valeur acquise (Earned Value) et coût réel (Actual Cost)

Table des Lois et Règles Loi 1: Frederick Brooks sur les ressources Loi 2: le Tiers de Napoléon sur la résistance à tout changement Loi 3 : Chaise vide Loi 4 : Effet Pygmalion Loi 5: Loi du Guépard - capacité à prendre une décision en un clin d’œil Loi 6 : Les 5 Péchés capitaux du Manager de Projet Loi 7 : Syndrome de l'étudiant Loi 8 : Loi de Parkinson Loi 9 : Syndrome du calendrier Loi 10: Règle de Robert Townsend sur les embauches pour un poste

Table des Definitions Définition 1: Scope ou Scope d'un projet Définition 2: Scope Creep ou Dérive du scope Définition 3: Stakeholders ou Parties Prenantes Définition 4: Identifier les Stakeholders Définition 5: Projet Définition 6: Business Case Définition 7 : Cycle de vie d'un projet Définition 8 : Méthodologie Définition 9 : Manager de Projet Définition 10 : Management du projet Définition 11: Charte d'un projet Définition 12: WBS Définition 13: Élaboration Progressive

Définition 14 : Risque Définition 15: Processus Définition 16: Technique Définition 17: Jugement d'expert Définition 18: Brainstorming Définition 19: Techniques Delphi Définition 20: PERT Définition 21: Technique des 3 Points Définition 22: Elaboration Progressive Définition 23: Méthode des antécédents Définition 24: Lead - Lag Définition 25: Chemin Critique Définition 26: Planification par vague (Rolling Waves) Définition 27: Fast Tracking Exécution accélérée par chevauchement Définition 28: Crashing – Compression

des délais Définition 29: La méthode de la chaîne critique Définition 30: Earned Value Technique (EVT) - technique de la valeur acquise Définition 31: Outils

Table des Figures Figure 1: Le management de projet s'industrialise Figure 2: Pont Rajeev Ghandi Figure 3: un projet est comme une course de voiture Figure 4: Retour sur Investissement (ROI) Figure 5: Pyramide de succès d'un projet Figure 6: Taux de succès des projets IT Figure 7: Triple Contrainte Figure 8: Quadruple Contrainte Figure 9: Projet ETC Figure 10: cycle de vie « haut » et « bas » d'un projet de Els van Mourik et Danny Hearty

Figure 11 : Projet vs Opération Figure 12 : Cycle de vie du Business Figure 13 : Projet à phase unique : en cascade Figure 14: Méthodologie customisée à l'image de l'organisation Figure 15: Choix de la méthodologie en fonction des exigences et de la technologie Figure 16: Projet simple : Exigences claires et connues Figure 17: Projet complexe - Exigences presque connues et claires Figure 18: Projet complexe - Exigences très peu connues et pas claires Figure 19 : Les paramètres dynamiques d’un projet

Figure 20: Les Facteurs Environnementaux d’un projet Figure 21: Iceberg de la culture Figure 22: chacun fait un pas vers l’autre pour combler le gap culturel Figure 23: Les 9 domaines de connaissances définis dans le PMBoK® Figure 24: Les Intérêts du Business d'abord Figure 25: Management de l'intégration du projet Figure 26:Processus de Management de problèmes Figure 27: Plan de Management du changement de Scope Figure 28: Piloter et Diriger l’exécution du projet

Figure 29 : Cycle de planification Exécution - Contrôle et Suivi Figure 30: Management du Scope du projet Figure 31: Management du délai du projet Figure 32 : Un projet implique un groupe d’activités interreliées Figure 33: Management du coût du projet Figure 34: Management de la qualité Figure 35: Management des Ressources Humaines du projet Figure 36: Joie d'un Manager de Projet jouant au golf avec son équipe projet Figure 37: Management des Communications du projet

Figure 38: Risque - Information vs Incertitude Figure 39: Management des Risques du projet Figure 40: Processus de management des Risques Figure 41: Analyse quantitative des risques - Diagramme de fréquence d’occurrence Figure 42: Analyse quantitative des risques - Courbe de probabilité Figure 43: Risque - Planning avec une deadline forcée Figure 44: Management des approvisionnements du projet (PMBoK®) Figure 45 : Courbe de peine et douleur

Figure 46: Comparaison des risques selon le type de contrat Figure 47: Groupe de processus de démarrage Figure 48: Groupe de processus de planification Figure 49: Groupe de processus exécution Figure 50: Groupe de processus de contrôle et suivi de projet Figure 51: Groupe de processus de clôture de projet Figure 52: La relation entre les 5 groupes de processus Figure 53: compétences d'un Manager de Projet "gold" – les 10 commandements Figure 54: Manager de Projet leader

avec vision et influence Figure 55: Style de leadership de Blake et Mouton Figure 56: Manager de Projet avec un sens aigu du détail du début jusqu’à la fin du projet Figure 57: Un Manager de Projet dansant son projet avec foi et passion Figure 58: Manager de Projet enthousiaste et congruent Figure 59: Un Manager de Projet capable de prendre des décisions Figure 60: Manager de Projet en interaction avec des stakeholders ayant chacun son humeur Figure 61: Manager de Projet avec un sens de l'écoute est un bon

communicateur Figure 62: Modèle de communication non-violente Figure 63: Manager de Projet qui élabore, exécute et contrôle son plan de jeu Figure 64: Manager un projet comme un ange même contre les démons Figure 65 : Projet ToIP Figure 66 : Activités en séquence Figure 67: Lien logique Début à Début Figure 68: Lien logique Fin à Début Figure 69: Lien logique Fin à Fin Figure 70: résultat d'un fast tracking d'un planning Figure 71: Planification et suivi des activités (Diagramme de Gantt)

Figure 72: Quel développement de carrière pour un Manager de Projet?

Bibliographie La matière de cet ouvrage a été façonnée aussi bien par de vécus personnels, organisationnels, sociétaux et culturels de managers de projet, que par les quelques ouvrages ci-dessous : Andrieux, Riana. Le monde des sociétés de service en technologie de l'information et de la communication. Bénévent Editions, 2007. Ascencio, Chloé, et Dominique Rey. Être efficace en Chine - Le management à l'epreuve de la culture chinoise. Pearson, 2010. Cole, Stephen Barker and Rob. brilliant

project management - what the best project managers know, say and do. Pearson , 2007. Covey, Stephen R. The 7 habits of Highly Effective People. Franklin Covey CO., 1989. Gerald I. Kendall, PMP and Steve C. Rollins, PMP. Advanced Project Portfolio Management and the PMO. J. Ross Publishing, 2003. Hallows, Jolyon. The Project Management Office Toolkit. Amacom, 2001. Heerkens, Gary R. Project Management. McGraw-Hill. Maders, Henri-Pierre. Manager une

équipe projet - Leadership Grilles de lecture Cas concrets. Editions d'Organisation. Maxwell, John C. The 21 Irrefutable Lawas of Leadership - Follow them and People will follow You. Thomas Nelson, 1998. Orr, Alan D. Advanced Project Management. Kogan Page, 2004. Project Management Institute. A Guide to the Project Management Body of Knowledge: (PMBoK Guide) 4th Edition. Project Management Institute, 2009. R. Max Wideman, PMI Fellow, Editor. Project & Program Risk Management: A Guide to Managing Project Risks and

Opportunities. Project Management Institute, 1992. Templar, Richard. Rules of Management: the Definitive Guide to Managerial Success (The Rules Series). Prentice Hall, 1st edition (29 Nov 2004). Whitten, Neal. Neal Whitten's NoNonsense Advice for Successful Projects. Management Concepts, 2004.