La plupart d’entre nous dans la profession de management de projet sont arrivés dans une profession qui s’était déjà développée. Par exemple, au moment où j’ai rejoint les rangs des praticiens en management de projet, on utilisait déjà des logiciels de planification depuis quelque temps. La tentative d’imaginer ce à quoi ressemblerait développer un planning détaillé de projet sans la disponibilité de cet outil est quasiment impossible. Bien que l’on ait enseigné à beaucoup d’entre nous comment le faire, nous n’allons pas probablement l’utiliser.
Comme la technologie continue à progresser, il y aura des outils, comme les applications des médias sociaux qui donneront la même sensation aux nouvelles générations de chefs de projet que la nôtre pour les outils de planification. Que ce soient des environnements de travail d’équipe collaboratifs, la messagerie instantanée, le courrier électronique et bien plus, la technologie fait partie intégrante de tout ce que nous faisons sur le lieu de travail.
Une constante qui restera est le besoin de communication efficace peu importe quels médias l’équipe utilise. Au milieu des années 1990s, j’avais commencé à manager des équipes virtuelles. Y compris dans mon engagement volontaire de leadership, la plupart de mes activités avec PMI ont été conduites dans un espace virtuel. J’ai dû rapidement développer des compétences dans la communication qui différaient beaucoup des interactions en face à face.
L’environnement virtuel est un endroit intéressant où la confiance est créée de façons très différentes. Je me rappelle que j’ai travaillé avec un autre volontaire de PMI pendant trois ans sans que nous ne nous soyons jamais rencontrés face à face. Peut-être l’élément le plus important dans la communication dans l’environnement virtuel est le ton utilisé. La raison à cela est que souvent le destinataire n’a pas l’avantage d’entendre l’expéditeur livrer le message. Comme tel, l’interprétation du message est laissée au destinataire basé sur sa connaissance ou manque de connaissance de l’expéditeur.
Ce qui est étonnant à ce propos est que souvent notre interprétation en tant que récepteurs de messages dépend énormément de notre état émotionnel. Par exemple, si je sors d’une réunion particulièrement mauvaise où les membres de l’équipe se disputaient et que j’ai eu plusieurs confrontations avec des clients ou des sponsors, cela aura un impact négatif quand j’interprète un message qui pourrait vouloir simplement fournir une critique constructive.
Considérons une instruction unique comme : “j’ai reçu votre produit et ai quelques questions à clarifier.” Si le chef de projet sort d’une réunion telle que celle j’ai décrite, voici comment il pourrait recevoir le message : “j’ai reçu votre produit et il y a beaucoup de problèmes qui exigeront des changements. Je vous contacterai par courrier électronique plus tard avec tous mes commentaires et retours d’information.”
Même si cela peut être exagéré, je crois que l’état émotionnel prend parfois le dessus. Je sais qu’à certaines occasions j’ai envoyé des courriers électroniques pensant que je les écrivais sur un ton neutre/calme et reçu une réponse négative. Voici quelques astuces que j’ai apprises en chemin pour aider améliorer la communication virtuelle :
Quelque chose qui doit ou peut être communiqué en personne ou par téléphone ne devrait pas être envoyé via le courrier électronique.
Si je dois envoyer un courrier électronique qui contient de mauvaises nouvelles, particulièrement s’il y a des problèmes, je trouve souvent utile d’avoir un avis externe. Il peut même être utile que cette personne lise votre message à voix haute pour voir si le ton qu’elle utilise est semblable à celui intentionné.
Faire des échanges répétés via courrier électronique sur des problèmes n’est pas sain. Sur certaines équipes nous avons établi des règles du jeu qui ont essentiellement autorisé les personnes à demander un temps mort. Cela signifiait que nous avions besoin d’arrêter le dialogue par courrier électronique pour avoir une discussion au téléphone ou en face à face.
Passez du temps à essayer de connaître la personne, même si elle est au téléphone, afin d’acquérir une meilleure compréhension de leur style de communication. De cette façon, quand vous recevez par exemple un de ses courriers électroniques, vous pouvez presque “entendre leur voix” plutôt que d’en être laissés à votre propre interprétation.
Quand vous recevez un courrier électronique particulièrement négatif, même s’il vous insulte, attendez. Ne répondez pas immédiatement. Si vous pouvez vous asseoir dessus pendant 24 heures, vous serez stupéfiés de combien le ton de votre réponse sera différent. J’ai constaté que quand je suis ennuyé par un courrier électronique je peux préparer la réponse, mais ne pas l’envoyer. Je garderai la réponse en attente pendant au moins deux heures avant de la revoir de nouveau. Je trouve souvent que je vais changer le message pour rendre la réponse moins agressive.
Sur une note finale, un conseil est que c’est un secteur qui a besoin d’être revisité fréquemment à cause des changements dans la dynamique. Il peut y avoir de nouveaux membres dans l’équipe, des modifications des priorités, des clôtures et démarrage de projets, ou des changements même technologiques qui auront un impact sur comment nous interagissons l’un avec l’autre. Plus nous pratiquons mieux nous y arrivons.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Beaucoup de ce que nous faisons au travail et dans notre vie privée est basé sur des assomptions. Les assomptions sont définies par le Guide de PMBOK comme: “factors that, for planning purposes, are considered to be true, real, or certain without proof or demonstration.”
“Des facteurs que, dans notre planification, nous considérons comme étant vrais, réels, ou certains sans preuve ni évidence.”
Autrement dit les assomptions sont en fait des croyances que nous tenons pour être vraies, mais sommes incapables de prouver. Le défi que nous rencontrons sur les projets n’est pas la définition des assomptions, mais plutôt de les ignorer. Nous comprenons intuitivement ce que sont les assomptions mais, quand on en vient à la planification, souvent nous ne comprenons pas comment les appliquer.
Dans mes ateliers de formation je dis aux participants si nous savons qu’une chose est en réalité fausse nous ne pouvons pas simplement construire l’assomption qu’elle est vraie. De même, si nous voulons atteindre un certain objectif ou « espérons » avoir le support d’une certaine partie prenante nous ne pouvons pas simplement supposer que le support se matérialisera.
Une de mes pauvres assomptions préférées émises par des équipes de projet ressemble à ceci :
“Nous assumons que le management supportera le projet”
ou
“Nous assumons que le projet a le support exécutif”
Celles-ci ne sont pas efficaces en matière d’assomption parce qu’il ‘est impératif pour le chef de projet et l’équipe de découvrir s’ils ont le support du management ou s’ils doivent aller construire ce support. Créer un plan et exécuter un projet dans l’espoir que le management le supportera est une bonne recette pour un désastre.
Laissez-moi illustrer ce que j’entends par cette citation très puissante par Miguel Angel Ruiz qui s’applique aux assomptions sur les projets :
“Ne faites pas d’Assomptions. Trouvez le courage de poser des questions et exprimez ce que vous voulez vraiment. Communiquez avec les autres aussi clairement que vous le pouvez pour éviter malentendu, tristesse et drame. Avec cette simple attitude, vous pouvez complètement transformer votre vie.”
Le point ici est que nous ne voulons pas confondre le rôle de planification avec celui de fabrication de suppositions parce que nous aurions la flemme d’aller au fond des questions difficiles qui sont des données d’entrée pour notre plan.
Un autre point important à garder aussi à l’esprit consiste en ce que s’il y a des problèmes ou des décisions que nous savons être vrais, nous ne pouvons en assumer autrement. Par exemple, si nous savons que l’organisation a défini un budget de 500K pour un projet nous ne pouvons pas assumer que le budget du projet augmentera quand débutera l’exécution.
Nous ne voulons pas non plus confondre assomptions et contraintes. Les contraintes sont les facteurs qui sont liés à la portée, au coût et aux délais du projet. En tant que tels, ils diffèrent beaucoup des assomptions. Les assomptions sont d’autre part une source majeure de risque sur le projet. Puisque nous ne pouvons pas prouver par les faits qu’un point existe, alors il y a un risque que notre croyance soit incorrecte.
Un des éléments les plus importants pour traiter les assomptions est d’admettre que le chef de projet doit continuellement évaluer si des conditions de projet ont abouti à la réalisation de ces assomptions ou les ont rendues obsolètes. Pendant le cycle de vie du projet il y aura les événements qui prouveront que des assomptions étaient fausses ou qui renforceront notre croyance. Quand ces événements ont lieu une évaluation doit être conduite pour déterminer l’impact sur le projet.
Comme je l’ai dit le concept d’assomption signifie quelque chose sur le papier, mais il est probablement beaucoup plus complexe dans la pratique. C’est là où l’expérience et les leçons apprises deviennent inestimables pour améliorer la performance de l’équipe de projet et les chances de succès.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Les avis des experts, quelque soit leur discipline, ne peuvent être un substitut à notre intelligence et notre capacité à raisonner.
Les exemples ne manque pas d’experts qui se sont trompés, même collectivement (crise financière, médicaments retirés du marché, innocuité de l’amiante…). Pourtant, ils fournissent souvent aux chefs de projet et au management une illusion de certitude. Hors, nous avons un enclin naturel à rechercher des certitudes pour prévenir les risques de mauvaises décisions, d’où une tendance à suivre aveuglément l’avis des experts.
Dans la vidéo qui suit, Noreena Hertz tient un discours à TED sur son propre métier d’experte et elle nous prodigue quelques conseils (à ne pas suivre aveuglément bien sûr) sur la distance qu’il convient d’avoir par rapport aux experts et les stratégies à adopter pour regagner en autonomie face à ceux-ci.
Vous aurez peut-être noté ces stratégies qui semblent couler de source et qui ne sont pourtant pas toujours suivies :
1. Être prêt à challenger les experts, à les questionner: Quelles méthodes ont-ils utilisés pour parvenir à leur recommandation? Quelles assomptions ont-ils fait en chemin? Sur quels domaines ont porté leurs investigations? …
2. Rechercher différentes opinions, si possible conflictuelles ou divergentes, pour se forger son propre avis sur la question.
3. Démocratiser l’expertise car les experts ne sont pas systématiquement ceux qui ont les titres les plus ronflants et les plus gros diplômes, les personnes avec une expérience pratique du domaine peuvent proposer de bien meilleurs avis et plus pratiques.
Les experts sont nécessaires et utiles mais il ne sont pas un substitut à votre propre réflexion.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Mon Garmin m’avait donné un parcours vers l’aéroport, mais j’avais le pressentiment qu’il se trompait. Donc j’ai suivi mon idée.
Comme je tournais à gauche au lieu d’à droite, j’ai entendu sa voix me malmener, me prier d’aller à droite.
Et je l’avoue, je me suis senti misérable. Je désobéissais. Je ne suivais pas les instructions.
Si nous en sommes rendus au point où nous sommes inconfortables à désobéir à un écran tactile de 12cm sur 10, alors noussavons que nous avons subi un lavage de cerveau. Il est en réalité bon (dans les faits, très probablement productif) d’identifier les Garmins, les chefs et les influenceurs dans votre vie et de les ignorer tout autant que vous voulez.
expérience personnelle
Vous est-il arrivé de suivre aveuglément une directive de votre management ?
La réponse est très probablement positive. Cela semble parfois nécessaire quand l’ordre répond à des impératifs légaux ou des contraintes business, ou bien s’il répercute les connaissances acquises et même s’il va à l’encontre de votre intuition personnelle. Cependant, un tel bandeau aveuglant d’obéissance inconditionnelle doit peut-être tomber quand l’ordre est en conflit avec vos convictions profondes.
J’en ai fait la douloureuse expérience il y a déjà de nombreuses années. Un proche collègue avait commis tellement d’erreurs de communication et d’attitude envers ses sponsors, son management et ses pairs, que la direction a jugé impossible de le maintenir dans son poste.
J’ai été convoqué par le directeur de département avant que l’intéressé ne soit informé des changements à venir. Sans me donner l’objet de l’entretien, on a commencé par me demander de m’engager à ne pas divulguer la suite de la discussion. Ce que j’ai accepté. Puis, on m’a exposé le point de vue de la direction sur la situation. On ne m’a pas donné l’opportunité de défendre cette personne qui, comme indiqué précédemment était un proche collègue. Le directeur m’a seulement demandé d’identifier le meilleur remplaçant possible et a réitéré l’ordre de garder le silence sur la situation.
Peu de temps après, la personne eut un entretien avec la direction qui lui exposa son point de vue. Bien sûr, il devint rapidement évident que je ne pouvais pas ne pas être au courant. Le remplaçant que j’avais proposé remplit d’ailleurs la fonction avec succès. Mais… que serait-il advenu si, bien qu’ayant donné ma parole, je m’étais parjuré et avais prévenu la personne ? Ou encore dit qu’aucun confrère à mon avis ne pouvait tenir le job ? Mon éthique personnelle en aurait souffert mais j’aurais certainement été moins affecté que ce ne fut le cas et, surtout, la personne impliquée aurait eu plus de temps pour se préparer à l’entretien difficile quel qu’en soit le résultat.
Depuis, quand on me demande de m’engager à tenir le silence et avant de répondre, je pose quelques questions préliminaires pour éviter ce conflit entre mes convictions et mes actes qui débouche toujours sur du stress et un fort malaise intérieur.
Pour reprendre l’analogie proposée par Seth, il faut parfois savoir suivre son propre sens de l’orientation, son compas intérieur, plutôt que les directives d’un GPS (ou d’un supérieur).
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Fournir une introduction professionnelle est une bonne manière de donner un coup de main des amis ou collègues. Mais vous ne devriez jamais accepter de réaliser une connexion si vous ne pouvez pas répondre des qualifications de la personne. Voici trois étapes pour décliner poliment une introduction si vous ne vous sentez pas à l’aise pour la faire :
1. Soyez transparent. Répondez honnêtement et expliquez pourquoi vous ne ferez pas cette introduction. Peut-être que vous estimez que la connexion ne convient pas ou ne mènera nulle part.
2. Donnez un lot de consolation. Proposez quelque chose d’autre. Donnez un avis ou des conseils sur ce que le demandeur peut faire la prochaine fois qu’ il fera une semblable demande.
3. Restez en contact. Si vous êtes enclins à reconsidérer sa requête plus tard, formulez le ainsi. Laissez la porte ouverte pour une nouvelle interaction.
Partenaire de DantotsuPM
momentum
partagez ce billet avec vos amis, collègues et relations professionnelles
La sensibilité aux cultures et à la communication inter cultures est un élément clé de réussite des chefs de projet qui travaillent à l’international. Je pense que cette petite vidéo amusante vous rappellera des souvenirs de situations similaires qui vous sont arrivées. Lesquelles ?
Pour ma part, je me souviens très clairement de l’employé japonais du Shinkansen, le TGV local, qui répondait négativement à notre demande de régler un billet de train par carte de crédit tout en hochant la tête de haut en bas et en souriant très gentiment. Il y avait là un profond décalage entre nos perceptions visuelles et auditives du message. Ce décalage provient essentiellement des différences de gestuelle dans nos cultures respectives. D’un coté le message visuel nous donnait l’impression d’une réponse positive alors que du coté auditif, la réponse verbale était « désolé, mais ceci n’est pas faisable ».
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
J’ai bien aimé dans cet article les cinq compétences que McKinsey a identifié comme étant au cœur du leadership:
trouver et donner du sens au travail
convertir des émotions telles que le stress et la peur en opportunités
savoir tirer partie de ses connections et de sa communauté
agir face aux risques
soutenir l’énergie qui est la force vive du changement
Le commentaire proposé dans ce document et disant que toute personne maîtrisant au moins une de ses compétences double sa capacité à conduire le changement me semble un peu excessif et l’autosatisfaction de ceux qui posséderaient les 5 tout autant sinon plus.
L’aspect « meaning », donner du sens, me semble en effet primordial
Et, pour donner du sens, il faut avoir une vision claire et savoir la communiquer.
bien comprendre les objectifs
les synthétiser
décliner la vision pour chacun
rester simple et très concis
Comment communiquer clairement si l’on n’a pas soi-même une vision très claire du projet? Il est avant tout critique de réussir à bien intégrer l’ensemble des objectifs du projet: financiers, métiers, techniques, humains, processus, stratégiques, tactiques… Un exercice à la fois complexe et nécessaire. Tant que l’on ne comprend pas dans le détail les objectifs du projet, comment les synthétiser et les restituer de manière simple et compréhensible.
De plus, la communication de la vision doit être adaptée à chacun de ses interlocuteurs:
l’équipe réalisatrice et technique,
les futurs utilisateurs des livrables du projet,
les sponsors et
autres partie prenantes,
etc.
Tous peuvent avoir des attentes différentes et néanmoins légitimes du projet. Il faut délivrer cette communication de manière extrêmement précise, simple et concise pour ne pas perdre ses interlocuteurs dans un brouhaha confus.
Plus facile à dire qu’à faire… Pourtant je l’ai déjà vu être exécuté avec virtuosité sur plusieurs projets et complètement raté sur d’autres.
Une vérité unique pour tous - One single truth
L’un de ces succès était un projet de déploiement de système informatique pour les finances et la logistique. La vision synthétique était que ce projet allait permettre à l’ensemble de la compagnie de partager une vérité unique sur ses comptes dans le monde entier, à tous les niveaux hiérarchiques, et dans chacune des divisions métier et des lignes de produit. Les déclinaisons de cette vision par type d’interlocuteur intégraient ce cœur de message et y ajoutaient des messages spécifiques aux diverses populations d’utilisateurs:
pour les techniciens l’aspect migration vers un progiciel phare du marché (Oracle eBusiness suite pour ne pas le citer),
pour les financiers une consolidation centralisée et unifiée dans une base de données commune accompagnée de l’adoption des meilleurs processus dans l’ensemble des organisations financières de notre entreprise dans le monde,
pour les décideurs, les tableaux de bord contenant des chiffres indiscutables, l’accès au données à travers des outils de construction de requêtes et rapports,
pour les utilisateurs, des formations, une interface homogène, ergonomique, fonctionnelle et des processus documentés en ligne.
Le second exemple auquel je pense est en fait un contre-exemple. Notre objectif était de déployer un système d’allocation automatique à des techniciens de maintenance des réparations à effectuer sur des matériels électroniques. Le message nous semblait clair: la solution, en optimisant les temps de trajet des techniciens, accroîtrait la satisfaction des clients et notre productivité. Le message retenu par le terrain fut seulement la partie accroissement de productivité. Celle-ci fut rapidement traduite par les principaux intéressés (les techniciens) en: accroissement de charge de travail, risques de pertes d’emploi, flicage et moins d’autonomie dans le choix des incidents à traiter. Hors, ce sont précisément eux qui pouvaient faire du projet un succès ou un échec. De plus, les responsables de clientèle qui auraient facilement compris et su expliquer les bénéfices à leurs clients et même aux techniciens furent les grands oubliés de la communication. Après une période de déploiement contrôlé sur un petit territoire géographique très réussie avec une opération en situation réelle survinrent les inévitables premiers problèmes techniques. Les techniciens amplifièrent ceux-ci et les responsables de clientèles supportèrent la fronde des techniciens. Ceci aboutit à l’abandon pur et simple du projet.
D’où cette leçon que j’ai retenue sur la nécessité pour le chef de projet d’acquérir cette capacité à savoir communiquer une vision claire afin d’accroître son leadership et aussi de s’assurer de n’oublier personne dans sa communication.
Je rapprocherais la capacité à manager l’énergie de la capacité à motiver et inspirer ses coéquipiers
créer un sentiment d’appartenance et de loyauté au projet
se connaître soi-même (son style personnel)
globaliser son approche
démontrer par l’exemplarité
Il est quasiment impossible de créer un climat de confiance sans démontrer chaque jour sa confiance en l’équipe, en ses membres et à notre capacité à réussir le projet ensemble. Il est souvent plus facile en première réaction de ne pas faire confiance. On peut vouloir reprendre une tâche précédemment allouée à une personne parce que les premiers livrables ne sont pas ce que l’on attendait d’elle en termes de contenu, de qualité ou de durée. On peut être tenté d’exiger un suivi lourd et/ou trop fréquent. On peut même simplement exagérément allonger la durée de certaines tâches d’une personne par manque de confiance en ses capacités… Hors, la moindre faille est fatale. Le manque de confiance sera immédiatement perçu par l’intéressé et par ses coéquipiers. Il faut énormément de temps pour gagner la confiance de l’autre et seulement quelques secondes pour la perdre.
Le sujet suivant de ce même thème qui est évoqué par McKinsey est la délégation. Celle-ci est d’autant plus difficile que le chef de projet est lui-même expert du domaine et capable d’exécuter parfaitement la tâche qu’il délègue. Il arrive aussi qu’une tâche nous paraisse si importante que l’on pense ne pouvoir la déléguer. Le leader commencera par s’entourer des bonnes compétences, meilleures que lui-même autant que possible. Il s’attachera à développer les ressources qui lui sont confiées en leur donnant des missions difficiles, critiques, complexes et en leur assurant le support nécessaire à leur réalisation. J’ai eu la chance de travailler avec quelques vrai leaders dans mon parcours et ce fut toujours un plaisir d’apprendre et de grandir à leur coté. Tous avaient des styles très différents mais en commun cette capacité à faire confiance. Une confiance que l’on ne veut décevoir.
D’autre part, on ne peut pas d’un coté dénigrer le projet et de l’autre demander à ses équipes de se défoncer pour livrer un excellent résultat dans les délais. Cela semble couler de source, et pourtant…Cet engagement sur le projet peut commencer par des petites choses toutes simples telles que la signature au bas de ses emails qui indiquera clairement son appartenance au projet, le message d’accueil sur le répondeur (« ici Pierre, leader du projet X au sein de la division Y chez Z »), les commentaires positifs à la machine à café, les deux phrases d’accroche pour répondre à la question classique sur son job et qui ne manqueront pas de faire l’éloge du projet…
Il y a également la notion d’authenticité chez les leaders: Avoir conscience de son style, de sa personnalité est également très important. Je m’explique : Êtes-vous plutôt directif, consensuel, paternaliste, orienté vers l’action ? Dans mon cas personnel, je suis très orienté vers l’action et j’ai un style assez participatif/coopératif. Lorsqu’il m’est arrivé sous la pression de basculer involontairement vers un style plus directif et tranchant, cela a été un fiasco. D’autant plus mal perçu que je n’étais pas à l’aise dans ce mode opératoire et que ce revirement était donc très mal ressenti: un manque d’authenticité. Néanmoins, j’ai eu l’occasion de travailler avec quelques patrons très directifs sans que cela pose réellement de problèmes à l’équipe car elle savait très bien à quoi s’en tenir, il restait authentique.
Je travaille depuis toujours me semble-t-il dans un environnement international. Les équipes sont géographiquement distribuées, les clients également. Nous utilisons l’anglais comme langue de travail commune avec bien sûr de grandes disparités de niveaux. Nous provenons de cultures différentes: latines, anglo-saxonne, indienne, cairote, japonaise… Lorsque l’on évolue dans un tel environnement, il faut impérativement penser global et prendre en compte les différences locales qui peuvent donner des résultats très différents pour une même activité.
Par exemple, lors de ma première visite professionnelle au Japon, j’ai très stupidement (mais je ne l’ai su que plus tard) essayé de faire avec mes collègues japonais la même session de brainstorming que celles réalisées avec beaucoup de succès en Europe et en Amérique du nord. Fiasco sur toute la ligne! Après un cours de rattrapage en rentrant sur la culture Japonaise, j’ai pu apprécier non seulement mon erreur mais aussi la situation très inconfortable dans laquelle j’avais mis involontairement mes collègues. J’avais rassemblé des personnes de niveaux hiérarchiques très différents dans une salle. Je leur ai allègrement demandé en commun et sans préparation d’échanger ouvertement leurs idées, de faire un « brainstorming ». Je n’en avais pas conscience mais j’allais à l’encontre même de leur mode de fonctionnement en équipe où l’on cherche à comprendre/tester à petites touches les positions de chacun avant d’avancer des idées.
Rien n’est inné dans ce domaine du travail entre personnes de cultures différente et rien n’est jamais acquis. Il faut sans cesse le garder à l’esprit.
J’ai eu sur le dernier point évoqué dans ce rapport : « démontrer par l’exemplarité », de vives discussions avec certains chefs de projet. Je vous laisserai être vos propres juges. Personnellement, je pense sincèrement que le leader chef de projet doit montrer l’exemple. Je pousse le bouchon un peu plus loin en conférence et face à une audience de professionnels en disant: premier arrivé, dernier parti, toujours ouvert et de bonne humeur, bosseur, positif… Bien sûr, ce n’est pas seulement le nombre d’heures qui comptent, c’est aussi ce que l’on met dedans: l’intensité. Pour autant, tous les grands leaders que j’ai côtoyés dans le domaine du management de projet sont de gros bosseurs et ne rechignent jamais à la tâche. Ils sont ouverts et approchables. Ils ont foi en l’avenir.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
PMI France-Sud a organisé à Monaco le 21 décembre une première rencontre de chefs de projet afin de leur donner l’opportunité de partager leur expérience et d’en apprendre davantage sur PMI France-Sud et les nombreuses activités de cette association professionnelle dans la région.
C’est à l’initiative de Katia Pijarowski, Program Manager chez Monaco Telecom, que fut organisée cette réunion d’amorçage d’une antenne monégasque de PMI France-sud qui rayonne déjà dans tout le sud de la France, de Sophia Antipolis à Lyon et Toulouse.
J’étais invité à cet événement pour y présenter un témoignage de mon expérience de mise en place de Portefeuille de Projets Informatiques dans une grande société internationale. Les nombreux participants ont pu échanger pendant cette réunion informelle et contribuer de leurs propres expériences. Jean-Claude Dravet, président d’honneur de PMI France-Sud et Jean-Michel Groleau, président en fonction, étaient également du déplacement et en ont profité pour tisser des liens plus étroits avec des passionnés du management de projet sur Monaco. Ceux-ci pourraient dès 2011 commencer à constituer un noyau actif et moteur pour monter une antenne locale; Organiser des événements sur le management de projet en principauté; Nouer des liens avec la Jeune Chambre Économique locale et les nombreuses entreprises et écoles ; Identifier des opportunités de promouvoir le PM en principauté…
Mais, revenons brièvement sur cette session d’échanges en commençant par quelques définitions :
Portfolio: Tous les projets et programmes entrepris par la division informatique
Programme: Un groupe de projets liés et managés de manière coordonnée.
Projets : de type « Baseline »: Série de taches de support ou de maintenance nécessaires au fonctionnement d’une application existante. Ou bien Nouveau: Un projet entrepris pour créer un nouveau produit ou service.
Les objectifs du portefeuille de projet
J’ai débuté la présentation en insistant sur la nécessaire analyse des objectifs que la division ou l’entreprise souhaite donner à ce processus. Dans mon cas précis, il s’agissait de maximiser le retour sur investissement des projets, de les aligner sur la stratégie de l’entreprise tout en limitant le nombre de projets et en améliorant la cohérence d’ensemble du portefeuille de projets informatiques.
Puis, nous avons discuté des rôles et responsabilités de chacun dans la mise en place d’une gestion de portefeuille projet : Clients, équipes projet, Portfolio Manager et instances décisionnelles pour prioriser les projets et décider de leur lancement (ou pas).
Les critères de priorisation et de décision
Nous retiendrons tout particulièrement l’importance de la phase d’élaboration des critères de priorisation et de décision.Ces critères sont au cœur du processus de management d’un portefeuille de projet car il vont permettre de prioriser les projets de manière simple, factuelle, indiscutable et homogène, avant de les soumettre à arbitrage final. Lors de cet arbitrage, les critères permettent de rationaliser le débat tout en restant avant tout des indicateurs que les plus hauts exécutifs au sein de l’entreprise vont combiner avec leur connaissance du business et de l’environnement concurrentiel pour parvenir à des décisions partagées et comprises de tous. Pendant cette phase e genèse des critères, les plus importants décideurs de chaque direction et division de l’entreprise doivent donc s’accorder sur un jeu très limité de critères simples et factuels qui seront appliqués à tout nouveau projet ainsi qu’à ceux en cours d’instruction : ce fut un challenge passionnant !
Les points très positifs de cet effort
Tous les membres du business furent réunis autour de la table pour discuter des priorités de l’entreprise et du portefeuille projets informatiques dans son ensemble ; Un bon travail de groupe permit d’établir les critères ; Une intégration du processus IT Portfolio dans celui de revue des investissements de l’entreprise fut mise en place et quelques projets éliminés assez tôt.
Les risques rencontrés dans ce cas précis
Une pression financière extrême en cours d’année (2003-2004) limita l’impact du processus et força certains partenaires dans leur ancien mode opératoire plus subjectif et égocentrique; des réorganisations impactèrent rapidement l’unité réussie autour des critères; certains décideurs firent preuve d’une importante résistance au changement.
En conclusion j’insiste sur le fait que de mon expérience « en management de portefeuille de projet, rien n’est définitivement acquis ».Il faut sans cesse se remettre en question et vendre et revendre à nouveau ce processus clé aux parties prenantes, nouveaux décideurs et aux plus hauts exécutifs de l’entreprise.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Bien démarrer le projet donne le ton pour tout le projet et positionne souvent l’équipe pour la réussite. Même si cela ne peut pas garantir le succès, avoir un mauvais démarrage de projet est dans la plupart des cas un premier signe d’alarme que le projet se dirige droit dans le fossé. L’événement le plus important pendant le processus d’initiation est la réunion de démarrage/de lancement. C’est cette rencontre entre l’équipe et les parties prenantes qui lance officiellement le projet. Cela pourrait bien être la réunion la plus importante parce que c’est souvent un test du chef de projet et de l’équipe par l’organisation pour voir si chacun est bien en place ou non.
Les bénéfices de la réunion de démarrage incluent :
Affirmation de l’appui du sponsor exécutif et des leaders seniors aux objectifs du projet.
L’explication de l’autorité et de la responsabilité du chef de projet à l’organisation pour obtenir l’appui et demander la coopération.
Une occasion pour l’équipe de se réunir sous la bannière du projet.
Donner les attentes des parties prenantes et de l’organisation quant à ce qui est couvert ou pas dans le périmètre du projet.
Recevoir les réactions sur toute omission dans les bénéfices potentiels du projet et commencer à construire/raffiner les exigences.
Il est important dans cette partie du processus de planification que le chef de projet travaille avec les parties prenantes pour assurer leur bonne représentation pendant la réunion.
Les participants à la session de démarrage devraient inclure :
Le sponsor exécutif et le chef de projet
Membres clefs du comité de direction
Tous les membres de l’équipe projet
Les représentants de l’organisation du client (interne ou externe)
Les représentants d’autres leaders de projets qui pourraient interagir avec ce projet (dans le cas d’un programme)
Puisque c’est la première occasion pour le chef de projet de démontrer sa force et ses compétences, il est important pour le PM de bien mener/faciliter cet événement. Cependant, pour que cette activité soit perçue positivement, le PM doit passer du temps avant la réunion pour la préparer.
Voici quelques suggestions pour aider le PM à bien se préparer pour l’événement et mener une réunion efficace :
La préparation d’une présentation qui est partagée avec les participants décrivant le « business case » pour le projet et la description de la portée à un haut niveau.
Discussion avec les membres de l’équipe des responsabilités et partager cette information pendant la réunion.
Mettre l’accent sur les éléments clefs de la charte de projet ou de la déclaration de travail ou du contrat client. Cela peut inclure des processus comme l’approbation de livrable ou le contrôle des modifications.
Discussion sur la terminologie pour parvenir à un accord sur un jeu de définitions communes.
Établir et/ou revoir les règles de vie d’équipe pour donner des attentes appropriées.
Fournir les détails de contact pour des parties prenantes clefs et exposer les étapes suivantes.
Détailler la suite proposée dans le processus et mettre en évidence les événements marquants prévus ou jalons pour le projet et s’assurer que chacun comprend ce qui arrivera ensuite.
L’identification d’une personne qui servira de preneur de notes de réunion pendant la session (autre que le PM) pour que les questions business, décisions et problèmes soient capturés.
La revue des éléments clefs du produit/service à livrer sur le projet afin de déterminer s’il y a bien une compréhension commune.
La conduite d’une session de « Team Building » si le temps permet et/ou si c’est approprié.
Une fois que l’on conclut la réunion avec succès, le processus de la réunion de démarrage n’est pas fini.
Il y a des activités de suivi que le PM et l’équipe doivent adresser pour assurer que la crédibilité se poursuive :
Revoir et distribuer les notes de la rencontre de démarrage incluant les points d’action.
Ajuster les composants clefs de la portée si certains ont été identifiés et mettre à jour la charte s’ils ont été agréés.
Communiquer sur le lancement du projet aux personnes non présentes ou non invitées à cette réunion.
Lancer une vérification de la portée détaillée et des sessions de validation des objectifs pour commencer la planification.
Documenter les modes opératoires et règles de vie avec l’équipe.
Communiquer les responsabilités convenues pour les divers membres d’équipe et parties prenantes.
Mettre à jour la documentation officielle comme la charte, SOW, etc …
Comme je l’ai mentionné, il n’y a peut-être aucune réunion plus importante que celle de lancement dans la vie du projet. Je m’en rappelle une, dans une organisation que j’ai rejointe, où le chef de projet est arrivé en retard et a quitté la réunion pendant 15 minutes pour faire les copies de l’ordre du jour (qu’il aurait du avoir au départ). Comme vous pouvez l’imaginer, cette réunion était peut-être la meilleure réunion de l’équipe projet qui a ensuite poursuivi sa descente aux enfers. Le projet ne s’est pas bien terminé.
Je suis sûr qu’il y a d’autres trucs que les praticiens ont relevé pendant leurs réunions de démarrage, donc merci de vos commentaires.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Jason Fried nous propose dans cette vidéo intitulée « Why work doesn’t happen at work » et présentée à TED cette année une théorie assez radicale à propos du travail : Le bureau n’est pas le bon endroit pour travailler ou du moins pas de la manière la plus productive.
Jason utilise certains des travers que nous rencontrons souvent au bureau pour étayer cette théorie: Des managers qui ne semblent être là que pour interrompre leurs employés qui eux ont du boulot, des réunions qui cannibalisent la journée de travail, des discussions entre collègues et autres interruptions en tous genres qui coupent notre élan dans nos phases de travail les plus productives…
Bien que poussé à l’extrême, l’argumentaire présente des mérites et les quelques conseils que distille Jason m’ont interpellé. Comme par exemple les « No Talk Thursday » que je ne trouve pas très recommandables ou encore l’annulation pure et simple de vos prochaines réunions. Ce qui m’inspire davantage et le principe sous-jacent de libérer du temps en continu pour être plus productif et créatif dès aujourd’hui comme de décréter des matinées sans réunion dans la semaine pour tous chaque semaine. Ou encore réduire la durée des réunions à 45′ au lieu d’une heure. De réduire le nombre participants aux réunions nécessaires au strict minimum…
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Quand vous avez une idée, proposition, ou recommandation en laquelle vous croyez, il est facile de présumer que l’obtention de son approbation sera facile. Si vous voyez combien l’idée est brillante, pourquoi tous les autres ne feraient pas de même ? Cependant, ce qui fait qu’une audience accepte une idée est souvent moins lié à l’idée elle-même qu’à comment vous la présentez. Quand vous avez besoin d’une approbation, ne supposez pas que simplement parce que l’idée est excellente, d’autres la verront comme vous — il faut les en convaincre.
Ce que disent les experts
Quand on en vient à l’obtention de l’approbation, le style peut être aussi important que la substance. « Le choix des mots a son importance, » dit John P. Kotter, Officier En chef de l’Innovation chez Kotter International et professeur honoraire à Harvard, dont le dernier livre est « Buy-in: Saving Your Good Idea from Getting Shot Down ». Et souvent, vous n’aurez qu’une seule opportunité devant votre patron, Comité exécutif, ou tout autre groupe qui décidera du destin de votre idée. « Les impressions initiales sont très fortes et elles peuvent être difficiles à contrecarrer, » dit Michel I. Norton, un Professeur Associé d’administration d’affaires à l’École de commerce de Harvard. Il ne s’agit pas de forcer l’idée et ses nombreux mérites dans la gorge de votre audience. Pensez à comment vous pouvez soigneusement faire passer votre idée à travers le processus d’approbation. « Plus les intérêts sont élevés, plus cela vaut la peine de prendre le temps de bien le faire, » dit Kotter. Voici cinq façons de donner une chance à votre proposition.
Former des alliances très tôt
Avant que vous ne présentiez une idée ou demandiez des ressources ou une approbation, c’est une bonne idée de la tester avec les responsables qui peuvent ou pas donner le feu vert. « Parfois cela ne nuit pas d’en parler un peu et de voir ce qui allume une étincelle dans les yeux des personnes ou les referme, » dit Kotter. Cela peut aussi faire remonter à la surface tôt dans le processus des questions ou des commentaires. Une fois que vous avez testé le terrain, vous pouvez prévoir des rencontres plus formelles avec des parties prenantes clefs pour demander leur support. Ces réunions servent trois buts :
Elles construisent la nécessaire adhésion à votre idée.
Elles montrent à vos parties prenantes que vous êtes intéressés par leurs avis.
Elles vous aident à améliorer et développer votre idée — il est possible que ces parties prenantes voient quelque chose dans votre idée que vous n’aviez pas vu.
Plus vous comprenez les sentiments de votre audience envers votre proposition, mieux vous pouvez vous préparer pour la faire approuver.
Préparez-vous, préparez-vous, préparez-vous
La manière dont vous répondez aux questions et soucis jouera un grand rôle dans votre succès ou échec. « En premier lieu, quand vous regardez quelqu’un trébucher sur une réponse, vous en déduisez qu’ils ne savent pas de quoi ils parlent, » dit Norton. Afficher de la confiance afin que les personnes pensent que votre recommandation est bonne. Avant que vous n’entriez dans votre présentation, réfléchissiez bien aux préoccupations possibles de votre auditoire. Dans Buy-In, Kotter et Lorne Whitehead exposent les quatre stratégies de base les plus souvent utilisées pour tuer une idée :
Remettre la décision à plus tard donc la retarder jusqu’à ce que mort s’en suive
Créer la confusion par un barrage de questions ou de détails inutiles
Remuer des problèmes ou craintes irrationnels
Vous attaquer personnellement
Plutôt qu’éviter ces attaques, Kotter et Whitehead suggèrent de « faire entrer les lions dans l’arène » pour critiquer votre idée. Ne marginalisez pas les personnes qui démoliront votre idée. Au lieu de cela, développez des réponses concises, honnêtes à chacune des tactiques qu’ils peuvent utiliser. En le faisant à l’avance, vous construisez votre confiance en vous-même et pouvez éviter de devenir inquiets ou en colère quand les gens défient votre idée.
La positionner pour votre auditoire
« Vous voudrez absolument façonner les détails de votre présentation selon votre auditoire, » dit Norton. Comment votre idée leur profite-t-elle ? Ils peuvent chercher à gagner en prestige, à réduire des coûts, ou une occasion de construire leur environnement autour de votre idée. Construisez votre présentation pour qu’elle parle directement de ces avantages et des manières dont votre auditoire en bénéficiera. En faisant cela, dit Kotter, vous créez un état d’esprit positif (positive mindset) autour de l’acceptation de votre idée ou proposition.
Faire simple
« La malédiction d’une présentation est que vous en savez beaucoup plus que votre auditoire sur le sujet, » dit Norton. Concentrez-vous sur un ou deux points principaux et évitez d’essayer de prouver votre connaissance. Soyez judicieux sur la quantité de données et d’analyse que vous présentez. Des présentations excessivement détaillées peuvent distraire votre auditoire, les faisant se sentir stupides de ne pas parvenir à vous suivre. De plus, ces détails peuvent consommer trop de temps. Même si votre auditoire demande plus de détails, soyez économe. Ici, Kotter indique qu’une des tactiques utilisées par les personnes pour tuer une idée est de présenter des informations qui font diversion ou demander tant de détails que les autres s’y perdent.
Répondre aux questions avec confiance
Quand vous présentez une nouvelle idée, « les personnes auront toutes sortes de réactions et voudront en discuter, » dit Norton. Beaucoup de présentateurs se laissent distraire en essayant de discerner l’intention derrière les questions ou les commentaires. Essaye-t-il de me rejeter ? Déteste-t-il l’idée ? N’a-t-elle pas confiance en mon jugement ? Ne vous donnez pas la peine d’essayer de découvrir ces motivations. Concentrez-vous sur répondre à la question aussi simplement et franchement que possible. Peu importe l’agressivité, le comportement négatif, ou apparemment idiot que la question peut refléter, « Vous voulez ressortir comme un homme d’état, » dit Kotter. « Traitez-la comme une question raisonnable venant d’une personne raisonnable. »
Si vous recevez une question hors sujet ou potentiellement déviante, vous pouvez répondre à la question que vous auriez aimé que la personne pose au lieu de celle-ci. Dans un papier de réflexion récent « l’art de répondre à une mauvaise question de la bonne façon » Norton et Todd Rogers ont trouvé que l’on a plus confiance dans les personnes qui se dérobent astucieusement à une question qu’en ceux qui y répondent de manière moins élégante (people who « artfully dodge » questions are trusted more than those who respond directly to questions in a less elegant way). « Si nous savons que quelqu’un esquive la question, nous ne l’aimons pas. Mais très, très souvent, nous ne le remarquons pas, » dit Norton. Vous pouvez donner une réponse qui est vaguement rapprochée de la question, mais qui ramène avec assurance votre auditoire sur votre point principal.
Principes à garder à l’esprit
Faire :
Rencontrer vos parties prenantes importantes avant d’avoir besoin de leur approbation formelle
Présenter votre idée en termes d’avantages dont votre auditoire tirera profit
Répondre aux questions avec concision et assurance
Ne pas faire:
Supposer que votre auditoire pensera que c’est une bonne idée simplement parce que vous le faites
Écraser votre auditoire avec une analyse détaillée ou des spécificités
Devenir défensif ou se fâcher quand les gens questionnent votre idée
Ami Gallo, l’auteur de ce billet nous propose ensuite dans l’article original 2 exemples précis que vous pourrez lire dans l’article original : Construire et démultiplier les alliances ; Persister de manière cohérente.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Par Jean-Baptiste JOURDANT, Responsable de l’offre Management de projet chez CSP Formation
« -C’est plus possible ! C’est nous qui devons être en relation avec le prestataire ! Tu n’as pas le droit de leur parler en direct !
– OK, OK ! Pas besoin de s’énerver. Je voulais juste accélérer le mouvement et m’assurer que les informations passent bien des utilisateurs aux développeurs…»
Moi, je veux bien. Si le patron de la DSI le dit, je ne vais pas m’y opposer. Mais s’ils connaissaient un peu le sujet, ça m’arrangerait pour mon projet. Comment je vais faire maintenant ? Je suis le chef de projet, mon patron, c’est le commanditaire du projet et je n’ai pas de droit de parler à mes prestataires ! De plus, il y a un nombre d’intermédiaires hallucinants entre les extrêmes de ce projet, de l’utilisateur final au développeur. Avec une dégradation systématique de la compréhension du sujet à chaque étape. Comment faire ?
Avant tout, de quoi parle-t-on ?
Voyons la nature des interlocuteurs possibles sur un projet, dans la chaîne de responsabilités. Ces définitions ne sont pas universelles d’ailleurs et peuvent recouvrir différentes réalités suivant les domaines dans lesquels elles sont utilisées.
La Maîtrise d’Ouvrage (MOA) : c’est donneur d’ordre au profit de qui l’ouvrage est réalisé. En gros, le client.
La Maîtrise d’Œuvre (MOE) : c’est l’entité chargée de réaliser l’ouvrage. Le responsable des opérations nécessaires à son achèvement.
Les délégués : parfois, chacune de ses entités délègue tout ou partie de leur responsabilité à des spécialistes.
On parle de MOAD (MOA déléguée, capable de prendre des décisions) ou AMOA (Assistance à MOA, plutôt exécutante). On peut avoir des entités internes spécialisées (un bureau des projets, par exemple, dans son rôle support) ou des consultants externes.
On parle aussi de MOED (MOE déléguée, avec fort niveau d’engagement) ou d’assistance à MOE (interventions ponctuelles ou exécutions). Ce sont des sous-traitants ou prestataires qui assurent ces fonctions.
La chaine de la « dé-valeur »
Je reviens maintenant sur mon projet de SI, que j’illustrais par le dialogue d’introduction.
Dans la première organisation mise en place, le CP MOA est placé comme « coordinateur » central du projet, avec une structure interne « MOAD » en support des opérations méthodologiques « projet ». Peu de rapport entre cette structure MOAD et la MOE sous-traitée.
Dans cette organisation, 2 comités de pilotage sont mis en place : Comité externe (CP MOA et client externe) et un comité de pilotage interne (CP MOA et CP MOAD). Avec évidemment les hiérarchies concernées. Le responsable et pilote de la réalisation est bien entendu le CP MOA, qui dans les faits cumule (en interne) les responsabilités de MOA et MOE, puisque la MOE est externe.
Évidemment, chaque sous-organisation produit ses tableaux de bord et a sa propre vision de l’avancement et de la santé du projet.
Suite à la soufflante du DSI, une nouvelle organisation est peu à peu mise en place.
Dans cette organisation, la MOA reste dans un rôle purement « défense des intérêts de son client » (commanditaire et utilisateurs). La structure interne de support aux projets reprend un rôle de MOE et devient responsable de la réalisation devant la MOA. Les comités mis en place deviennent le Comité de pilotage de « l’ouvrage » (CP MOA avec les utilisateurs) et le comité de pilotage de « l’œuvre » (CP MOE avec le prestataire et le CP MOA).
Quel bazar !
Dans cette nouvelle disposition à trois chefs de projets et deux comités de pilotage, une couche théorique s’est ajoutée et l’utilisateur s’est encore éloigné du producteur.
Comment faire pour limiter les incompréhensions entre ces représentants ?
Comment assurer une bonne adéquation entre le besoin et le livrable ?
Est-il vraiment nécessaire d’avoir autant de chefs de projets… au même niveau, sur le même projet ?
Ne peut-on pas avoir un unique comité de pilotage ?
Rationalisons !
Tout d’abord les chefs de projets.
Le CP MOA n’est pas le chef de projet. Il porte le besoin et garantit la satisfaction du client. Il recueille, exprime, recadre, arbitre, informe. Il est MOA. On peut l’appeler CP MOA. Mais si un chef de projet MOE est nommé à l’intérieur de l’organisation, ce sera bien lui le chef du projet. Avec une relation « client-fournisseur » interne.
Le CP MOE, est celui qui coordonne l’ensemble des activités sur le projet. Il garantit 2 axes principaux : la communication transverse et l’application de la méthodologie de management de projet. Il s’assure de la bonne information des parties prenantes en temps réel, diffuse les tableaux de bord, gère les risques et s’assure de la résolution correcte de tout problème.
La MOE déléguée pour réaliser l’ouvrage met en place une équipe projet de producteurs et d’experts. Chef de projet MOE délégué ? Oui, bien sûr, mais dans son entité propre.
Nos deux comités de pilotage ?
Plus vraiment. Il reste UN comité de pilotage animé par le CP MOE. De part et d’autres (côté client et côté prestataire) restent des réunions de suivi, de surveillance, d’avancement. Mais il ne s’agit plus de pilotage.
Les livrables méthodologiques ?
Entre les deux organisations, les tableaux de bords (TDB) ont été recentrés sur le chef de projet (CP MOE) et le cahier des charges fonctionnel lui a échu. Si ce n’est pas le cas, il risque de rester une « boîte aux lettres », un organisateur, un gestionnaire de projet. L’appropriation de la maîtrise fonctionnelle est l’espace critique de sa crédibilité.
Conclusion ?
En phase d’avant projet (type SI), lorsque la solution n’est pas encore définie, la MOA définit un pilote de cette phase. Un « chef de projet » en charge de cadrer le projet, identifier les risques majeurs, construire un business plan, recueillir la structure des besoins, évaluer pertinence et faisabilité.
Il peut être le chef de projet MOE responsable de la réalisation, en dialogue avec le commanditaire. Mais, il peut aussi n’être que « l’avocat » de la MOA.
Dans ce cas, il sera important lors de la phase de planification du projet et au plus tard au démarrage de l’exécution, d’avoir défini clairement les rôles et responsabilités de la chaîne de transformation du besoin en charges fonctionnelles, en solution technique puis en solution opérationnelle.
Et quelle que soit l’organisation choisie, le chef de projet, unique, devra :
1° garantir la plus grande fluidité de la communication entre acteurs « éloignés », en créant autant de points de rencontres que nécessaires,
2° maîtriser l’application des meilleures pratiques méthodologiques tout au long du projet.
Responsable de l’offre Management de projet chez CSP Formation
« -C’est plus possible ! C’est nous qui devons être en relation avec le prestataire ! Tu n’as pas le droit de leur parler en direct !
– OK, OK ! Pas besoin de s’énerver. Je voulais juste accélérer le mouvement et m’assurer que les informations passent bien des utilisateurs aux développeurs…»
Moi, je veux bien. Si le patron de la DSI le dit, je ne vais pas m’y opposer. Mais s’ils connaissaient un peu le sujet, ça m’arrangerait pour mon projet. Comment je vais faire maintenant ? Je suis le chef de projet, mon patron, c’est le commanditaire du projet et je n’ai pas de droit de parler à mes prestataires ! De plus, il y a un nombre d’intermédiaires hallucinants entre les extrêmes de ce projet, de l’utilisateur final au développeur. Avec une dégradation systématique de la compréhension du sujet à chaque étape. Comment faire ?
Avant tout, de quoi parle-t-on ?
Voyons la nature des interlocuteurs possibles sur un projet, dans la chaine de responsabilités. Ces définitions ne sont pas universelles d’ailleurs et peuvent recouvrir différentes réalités suivant les domaines dans lesquels elles sont utilisées.
La Maitrise d’Ouvrage (MOA) : c’est donneur d’ordre au profit de qui l’ouvrage est réalisé. En gros, le client.
La Maitrise d’Œuvre (MOE) : c’est l’entité chargée de réaliser l’ouvrage. Le responsable des opérations nécessaires à son achèvement.
Les délégués : parfois, chacune de ses entités délègue tout ou partie de leur responsabilité à des spécialistes.
On parle de MOAD (MOA déléguée, capable de prendre des décisions) ou AMOA (Assistance à MOA, plutôt exécutante). On peut avoir des entités internes spécialisées (un bureau des projets, par exemple, dans son rôle support) ou des consultants externes.
On parle aussi de MOED (MOE déléguée, avec fort niveau d’engagement) ou d’assistance à MOE (interventions ponctuelles ou exécutions). Ce sont des sous-traitants ou prestataires qui assurent ces fonctions.
La chaine de la « dé-valeur »
Je reviens maintenant sur mon projet de SI, que j’illustrais par le dialogue d’introduction.
Dans la première organisation mise en place, le CP MOA est placé comme « coordinateur » central du projet, avec une structure interne « MOAD » en support des opérations méthodologiques « projet ». Peu de rapport entre cette structure MOAD et la MOE sous-traitée.
Dans cette organisation, 2 comités de pilotage sont mis en place : Comité externe (CP MOA et client externe) et un comité de pilotage interne (CP MOA et CP MOAD). Avec évidemment les hiérarchies concernées. Le responsable et pilote de la réalisation est bien entendu le CP MOA, qui dans les faits cumule (en interne) les responsabilités de MOA et MOE, puisque la MOE est externe.
Evidemment, chaque sous-organisation produit ses tableaux de bord et a sa propre vision de l’avancement et de la santé du projet.
Suite à la soufflante du DSI, une nouvelle organisation est peu à peu mise en place.
Dans cette organisation, la MOA reste dans un rôle purement « défense des intérêts de son client » (commanditaire et utilisateurs). La structure interne de support aux projets reprend un rôle de MOE et devient responsable de la réalisation devant la MOA. Les comités mis en place deviennent le Comité de pilotage de « l’ouvrage » (CP MOA avec les utilisateurs) et le comité de pilotage de « l’œuvre » (CP MOE avec le prestataire et le CP MOA).
Quel bazar !
Dans cette nouvelle disposition à trois chefs de projets et deux comités de pilotage, une couche théorique s’est ajoutée et l’utilisateur s’est encore éloigné du producteur.
Comment faire pour limiter les incompréhensions entre ces représentants ?
Comment assurer une bonne adéquation entre le besoin et le livrable ?
Est-il vraiment nécessaire d’avoir autant de chefs de projets… au même niveau, sur le même projet ?
Ne peut-on pas avoir un unique comité de pilotage ?
Rationalisons !
Tout d’abord les chefs de projets.
Le CP MOA n’est pas le chef de projet. Il porte le besoin et garantit la satisfaction du client. Il recueille, exprime, recadre, arbitre, informe. Il est MOA. On peut l’appeler CP MOA. Mais si un chef de projet MOE est nommé à l’intérieur de l’organisation, ce sera bien lui le chef du projet. Avec une relation « client-fournisseur » interne.
Le CP MOE, est celui qui coordonne l’ensemble des activités sur le projet. Il garantit 2 axes principaux : la communication transverse et l’application de la méthodologie de management de projet. Il s’assure de la bonne information des parties prenantes en temps réel, diffuse les tableaux de bord, gère les risques et s’assure de la résolution correcte de tout problème.
La MOE déléguée pour réaliser l’ouvrage met en place une équipe projet de producteurs et d’experts. Chef de projet MOE délégué ? Oui, bien sûr, mais dans son entité propre.
Nos deux comités de pilotage ?
Plus vraiment. Il reste UN comité de pilotage animé par le CP MOE. De part et d’autres (côté client et côté prestataire) restent des réunions de suivi, de surveillance, d’avancement. Mais il ne s’agit plus de pilotage.
Les livrables méthodologiques ?
Entre les deux organisations, les tableaux de bords (TDB) ont été recentrés sur le chef de projet (CP MOE) et le cahier des charges fonctionnel lui a échu. Si ce n’est pas le cas, il risque de rester une « boîte aux lettres », un organisateur, un gestionnaire de projet. L’appropriation de la maîtrise fonctionnelle est l’espace critique de sa crédibilité.
Conclusion ?
En phase d’avant projet (type SI), lorsque la solution n’est pas encore définie, la MOA définit un pilote de cette phase. Un « chef de projet » en charge de cadrer le projet, identifier les risques majeurs, construire un business plan, recueillir la structure des besoins, évaluer pertinence et faisabilité.
Il peut être le chef de projet MOE responsable de la réalisation, en dialogue avec le commanditaire. Mais, il peut aussi n’être que « l’avocat » de la MOA.
Dans ce cas, il sera important lors de la phase de planification du projet et au plus tard au démarrage de l’exécution, d’avoir défini clairement les rôles et responsabilités de la chaine de transformation du besoin en charges fonctionnelles, en solution technique puis en solution opérationnelle.
Et quelle que soit l’organisation choisie, le chef de projet, unique, devra :
1° garantir la plus grande fluidité de la communication entre acteurs « éloignés », en créant autant de points de rencontres que nécessaires,
2° maîtriser l’application des meilleures pratiques méthodologiques tout au long du projet.
partagez ce billet avec vos amis, collègues et relations professionnelles
Nous sommes tous familiers de la « to-do » liste (la liste des choses à faire) pour augmenter notre productivité. Une autre liste qui peut débrider notre productivité est la « not to do list »: la liste des choses que nous ne devrions pas faire. En étant conscient de quoi éviter, nous canaliserons automatiquement notre énergie sur les choses que nous voulons faire. Jouer sur ces deux listes en parallèle maximisera notre performance.
Si vous voulez faire grimper votre productivité au prochain niveau, voici 9 habitudes à éviter :
1. Essayer de tout faire
Je mentionne souvent la règle du 80/20 dans mes articles parce qu’elle est vraie. Et je la répéterai encore. Non, toutes les tâches ne sont pas égales. Chaque tâche a sa propre importance. En fait avec la règle de 80/20, 20% des tâches sur notre liste de to-do fournissent 80% de la valeur. Coupez ainsi férocement dans votre liste de to-do et éliminez les 80% de tâches à faible valeur. Quand vous l’avez réduite au minimum essentiel, focaliser comme un laser toute votre énergie sur les 20% à forte valeur. Faites la même chose le jour suivant. Triez et répétez. Gardez seulement les choses absolument importantes et laissez les autres de coté.
J’avais l’habitude de penser que je devais répondre à tous les emails jusqu’à ce que j’aie constaté que pas tous mes emails recevaient de réponse. En fait, beaucoup n’en recevaient pas, même lorsqu’ils concernaient des réponses de suivi aux courriers de lecteur demandant de l’aide. Apparemment, tout l’effort nécessaire à méticuleusement dactylographier, exprimer et composer mes courriers ne me menait nulle part. Je pouvais rester coincé la journée entière dans mes emails sans produire autre chose qu’une augmentation des courriers envoyé dans ma boîte d’envoi. Aussi ai-je commencé à répondre sélectivement aux emails de priorité plus élevée, et le monde ne s’est pas arrêté de tourner. En fait, j’ai maintenant plus de temps pour créer davantage de contenu et d’articles de valeurs pour les lecteurs, ce qui est une grande réussite pour chacun.
3. Penser devoir tout faire immédiatement
Indépendamment de ma liste de choses à faire et à ne pas faire, j’ai également une liste des choses à faire plus tard. C’est un ensemble de choses qui arrivent pendant ma journée, habituellement administratives, stupides – de petites tâches ennuyeuses qui ne prennent pas beaucoup de temps mais ne sont pas très importantes non plus. Laisser tomber ce que je suis en train de faire pour travailler sur celles-ci peut être disruptif, donc je les place dans ma liste des choses à faire plus tard. Puis, en fin de journée, je traite ce lot en une seule fois et fait disparaître toutes ces tâches. C’est beaucoup plus efficace.
De même pour mes emails, J’ai un dossier « à répondre d’ici Mardi/Jeudi/Samedi » dans lequel j’archive des courriers pour les traiter ces jours respectifs.
4. Remettre à plus tard des tâches importantes
La temporisation est assassine. Cela peut sembler bonne idée de remettre à plus tard la tâche actuelle, mais cela prépare seulement un embouteillage à venir, et cela n’en vaut pas la peine. Attelez-vous dès maintenant à vos projets les plus importants et cessez de les remettre à plus tard. Parmi toutes les personnes que j’ai rencontrées pendant toute ma vie, je n’en ai jamais trouvé une qui obtienne une joie et un bonheur authentiques grâce à la temporisation. Ceux qui prétendent être heureux en temporisant vivent habituellement dans une illusion, alternant « oh de moi suis heureux comme je suis », « j’aimerais ne pas avoir à faire ceci » avec « je souhaiterais avoir commencé plus tôt » en l’espace de quelques secondes.
Ne vous infligez pas une telle situation. Il s’agit simplement de se mettre en route. Une fois que vous commencez, cela devient plus facile. J’ai écrit 11 étapes simples et pourtant pratiques qui peuvent vous aider à sortir de la spirale de la temporisation.
5. Essayer d’obtenir la perfection dès la première fois
Fait intéressant, c’est le perfectionniste en chacun de nous qui cause bon nombre à temporiser (voyez #4). Si votre côté perfectionniste vous empêche de réaliser des choses en premier lieu, c’est quelque chose que vous devriez regarder de près. Entrez dans une approche par brouillons. Commencez par travailler à une 1ère ébauche, où vous travaillez sur le contenu central, puis revenez-y pour une 2ème ou 3ème passe où vous entrez alors dans les petits détails. Autorisez-vous à faire les erreurs que vous pourrez corriger plus tard. Il est beaucoup plus facile d’avancer de cette façon que d’essayer de faire tout juste dès la 1ère version. Je fais ceci quand j’écris mes articles et mes livres et ma productivité est plus importante.
6. Être accroc aux détails
Être orienté sur les détails est une bonne chose. Je suis moi-même une personne très orientée sur les détails. Cependant, ne soyez pas tellement hanté par des détails qu’ils vous empêchent d’avancer. Ceci aura-t-il de l’importance dans 1 an ? Dans 3 ans ? 5 ans ? Si ce n’est pas cas, peut-être n’est-il pas si intéressant s’inquiéter à ce sujet en ce moment. Recherchez la vue d’ensemble ; c’est plus important pour vous.
7. Ne pas avoir de buts clairs
Connaissez-vous vos buts pour le mois en cours ? Que diriez-vous de ceux de cette année ? Et de ceux de l’année prochaine ? Si vous pouvez répondre à ces 3 questions avec une certitude absolue et avec concision, alors vous pouvez y aller. Sinon, peut-être serait-il bon de passer un peu de temps pour y réfléchir. Même si cela peut prendre un peu de temps au départ, après avoir établi vos priorités, vos journées deviennent très affûtées et focalisées. J’ai des objectifs et cibles mensuels clairs vers lesquels je travaille et que je passe en revue chaque semaine, et cela m’aide à rester sur les rails vers mes buts à plus long terme. Ce mois, mon plus grand but est de finir et livrer mon 2ème livre. Être conscient de ce but m’a aidé à éloigner les tâches sans importance et à donner la priorité à celles qui sont essentielles pour le lancement, ainsi je peux atteindre l’objectif de livraison. En ce moment, tout est sur les rails et je suis excité de voir les résultats finaux. Lisez la stratégie #1 de 13 stratégies « to jumpstart » votre productivité pour plus de détails sur comment fixer vos objectifs.
8. Ne pas faire de pauses
Les humains ne sont pas des robots. Alors que les robots peuvent soutenir un rendement constant sur une longue période, nous devons nous reposer et nous recharger. Programmez une petite pause entre vos heures de travail, disons de 5 ou 10 minutes, et prenez un peu l’air. Vous trouverez votre concentration bien plus élevée quand vous vous remettrez au travail.
9. Essayer de satisfaire chacun
J’aime cette citation de Colin Powell “Trying to get everyone to like you is a sign of mediocrity”, qui indique qu’essayer de faire que tout le monde vous aime est un signe de médiocrité. Vous n’allez jamais pouvoir contrôler ce que d’autres pensent, aussi ne passez pas trop d’heure à transpirer là-dessus. Au lieu de cela, travaillez sur les choses que vous pouvez davantage contrôler : vous-même, vos émotions, vos pensées et vos actions. Dépensez votre énergie dans le processus de création, et sur les personnes qui méritent votre attention et votre amour. Essayez de faire ceci pendant une semaine – vous y trouverez bien plus de récompenses.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Une fois n’est pas coutume, je ne suis pas 100% en ligne avec les propositions de Ty, traduites ci-dessous.
En particulier sur sa neuvième recommandation qui suggère de toujours répondre par « oui » aux demandes des parties prenantes en indiquant simplement le coût associé à ce « oui ».
Par exemple : « Oui, nous pouvons réaliser cette nouvelle fonctionnalité en augmentant le budget de 10% et en décalant d’un mois la date de livraison. »
Mon expérience personnelle est que trop souvent la contrepartie ou les conditions nécessaires pour autoriser ce « oui » seront occultées par une grande majorité des parties prenantes qui n’entendront que le « oui » de début de phrase. Or, les conditions qui permettraient ce « oui » n’existent pas au moment où il est prononcé : besoin de budget additionnel, report au niveau des délais, ajouts de personnels et de compétences, compromis sur le contenu des livrables ou la qualité…
Je suggérerais donc, dans cette situation, de choisir d’adopter la position de dire « non » suivi d’un « sauf à » faire ceci ou cela (à augmenter les ressources, à réduire les exigences, à reporter la date de livraison…).
Par exemple : « Cet augmentation de fonctionnalité semble en effet attractive, mais nous ne pouvons pas y répondre…
… sauf à augmenter le budget de 10% et décaler la date de livraison d’un mois ».
Ceci permet à mon avis d’être beaucoup plus clair sur l’incidence de passer outre à ce « non ».
Maintenir une ligne de communication ouverte et efficace avec les parties prenantes est important. Il y a deux ou trois ans je suis tombé sur cette liste d’astuces pour mieux présenter aux parties prenantes, qui méritent d’être revues. Parfois il semble que l’efficacité d’une réunion de trente minutes puisse être conclue dans les dans soixante premières secondes. Les parties prenantes ont parfois des laps de temps d’attention très courts. Si vous ne captez pas leur attention dans les deux premières minutes, ils commenceront à vérifier leur courrier électronique et regarder l’horloge ou pire, quitteront votre réunion.
Toute personne impliquée dans un projet doit traiter avec des sponsors et des parties prenantes. Ayant cela en mémoire, voici dix astuces qui pourraient aider vos interactions :
1. Piquez leur curiosité : un ordre du jour est toujours une bonne idée, mais un bref résumé de ce qui sera discuté est encore mieux. En plus, on donne aux parties prenantes quelque chose à prendre dans la rencontre et cela leur permet de venir préparée avec des questions.
2. Ne supposez pas qu’ils connaissent le travail attendu de leur part en tant que partie prenante : Ils pourraient en avoir une vue de haut niveau, mais vous devrez probablement expliciter les détails.
3. Faites simple : Exposez-leur la situation en termes directs. Ne les noyez pas d’informations. Restez-en à l’essentiel. (Cependant, soyez prêt à entrer dans les détails s’ils commencent à poser des questions.)
4. Utilisez des chiffres et des images : PowerPoint est un excellent outil pour présenter des graphiques et des chiffres aux parties prenantes. C’est la façon dont elles se présentent les informations entre elles. Vous devriez en faire autant.
5. Parfois vous devez utiliser la logique : Acceptez le fait qu’il pourrait ne pas toujours y avoir des données pour supporter une situation particulière. Ne pas avoir de chiffres pour soutenir votre position pourrait rendre un bon argument problématique, dans ce cas vous devriez vous tourner vers une logique « si … alors … » pour expliquer une situation. Cependant, ne vous attendez pas aux mêmes résultats ou à la même réponse de la part des parties prenantes car avec elles les chiffres font loi.
6. Temporiser n’est jamais une bonne option : n’attendez pas qu’un problème soit évident — il est souvent plus difficile de résoudre le problème à ce moment-là.
7. Offrez toujours une solution : si vous venez exposer un problème sans offrir une solution potentielle, vous pourriez aussi bien demander les parties prenantes : « Virez-moi tout de suite. » Trouver des solutions fait partie de votre travail de chef de projet.
8. Spécifiez les actions qu’ils doivent entreprendre : si les parties prenantes doivent agir, ne supposez pas que ce sera évident pour elles. Récapitulez — sous forme de liste — quelles actions doivent être prises et quand.
9. Dites toujours » oui », mais assurez-vous qu’ils comprennent combien coûtera ce « oui« : les Sponsors et des parties prenantes n’aiment pas entendre « Non », donc ne le dites pas. Assurez-vous simplement qu’ils comprennent le coût de leur requête, alors ils peuvent juger par eux-mêmes si « oui » vaut vraiment le coup.
10. N’arrêtez pas de reporter sur le statut du projet parce que les parties prenantes arrêtent de l’exiger : la perception est la réalité. Si les parties prenantes perçoivent que vous ne faites rien : c’est que vous ne faites rien. Ne laissez pas votre tête être la suivante sur le billot.
Indépendamment de la méthodologie de management du travail de votre société, il y a beaucoup d’outils de management de projets disponibles pour faciliter la gestion des tâches et des délais qui vous aideront à communiquer plus efficacement avec les parties prenantes dans votre organisation. Que votre outil de management de projet facilite ou pas cette forme de communication, ignorer cette partie importante de votre rôle de chef de projet est dangereux. Que faites-vous dans votre organisation pour encourager une relation positive avec les parties prenantes ?
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
« Je vous ai dit ce dont j’avais besoin et vous avez lancé un projet pour y répondre mais je n’en ai plus entendu plus parler depuis. Où en êtes-vous? Où est le bout du tunnel ? Ce livrable correspond à mes attentes de l’an dernier, pas à ceux de cette année! Vous êtes trop lents, pas assez agiles, pas assez présents… »
De nombreux chefs de projet sont confrontés à ces commentaires de la part de leur clients et parties prenantes. L’effet tunnel y est pour quelque chose. En le supprimant grâce à des livrables fréquents ou en limitant ses effets grâce à des jalons d’avancement bien pensés, vous gagnerez en crédibilité et votre projet aura de bien meilleures chances de réussite.
(Comment éviter le syndrome du tunnel sombre et tortueux) de Bob McGannon, PMP
Souvent le projet pourtant bien conçu au départ finit en tas de ferraille qui prend la rouille à cause d’attentes inadéquates, ou de sponsors et parties prenantes clefs qui s’en désintéressent ou qui s’impatientent avec les projets qui ne délivrent pas de résultat assez rapidement. Ces projets, après la création d’un intérêt initial, semblent entrer dans « un tunnel tortueux et sombre » d’où l’on ne voit plus la lumière d’entrée du tunnel, où la sortie de tunnel n’est pas en vue et des jalons significatifs adéquats n’existent pas pour attester des progrès réalisés. Éviter ce piège n’est en aucune manière une question insignifiante, car cela demande davantage que la simple définition de jalons marquants pour votre projet. Une planification intense, un soin supplémentaire porté aux estimations et à la répartition de vos livrables par phases significatives est critique pour éviter cet « effet tunnel » redouté. Voici nos recommandations pour garder votre projet « dans la lumière de jour; » éviter son annulation ou sa baisse de priorité en raison « Syndrome du tunnel sombre et tortueux »
Établissez des jalons significatifs
Les jalons sont la base de chaque planning de projet bien construit. Ils établissent des points dans le temps où des événements significatifs ont été effectués, des livrables ont été produits, ou des passages de phase ont été atteints. Souvent ces événements marquants sont insérés dans le planning par des chefs de projet sans réfléchir avec une vue dans long terme sur les perceptions des parties prenantes. Bien sûr, il y a des jalons « naturels » comme les passages d’étapes qui sont appropriés. Cependant, si on définit et instaure des jalons en ayant à l’esprit la démonstration d’une manifestation significative de progrès coté business, un plus grand bénéfice sera obtenu de ces indicateurs de progrès du projet. La clef pour que cela fonctionne est de lier les jalons aux événements qui reflètent du but business qui a justifié d’exécuter le projet. Aussi, les jalons peuvent (et doivent !) être définis avant d’achever le planning détaillé.
Les jalons qui sont significatifs aux sponsors business peuvent être définis au moment, ou peu après, la création de la charte de projet. Ceux-ci peuvent ensuite être modifiés pendant la planification initiale et le développement de concept de la solution, avec la participation du sponsor et des parties prenantes. Ces jalons, créés et modifiés avec l’engagement du client, sont alors insérés dans un planning détaillé de projet, avec les événements marquants de progrès du projet comme le début d’une phase.
En travaillant sur la création de jalons significatifs, on devrait être attentif à s’assurer que « le langage de solution technique » ne s’introduise pas subrepticement dans les jalons. Cela fait peu de bien que de parler avec un sponsor peu intéressé par la technologie d’un concept technique comme la création d’un modèle de données informatiques. Bien que ce soit un événement marquant significatif dans la création d’un produit informatique, il a peu de pertinence pour un manager qui essaye de réduire le temps de rotation de son processus ou réduire ses dépenses! Il est certainement utile d’inclure des événements marquants techniques pour suivre de près le progrès de la perspective de l’équipe technique, mais utiliser seulement ces éléments comme jalons de projet pour les parties prenantes business est une invitation à cheminer par un très long « tunnel ». La création de jalons et leur suivi sont des choses à ne pas prendre à la légère!
Découpez le Projet en phases de 9 mois ou moins
La manière la plus fondamentale, et cependant souvent la plus difficile d’éviter le « tunnel sombre et tortueux » est d’éviter la tentation de créer un long projet d’une unique phase. Un principe fondamental des méthodologies « agiles », des projets plus petits ou de plus grands projets découpés en plusieurs phases de livraison sont très efficaces pour maintenir l’intérêt des parties prenantes de l’organisation dans le projet. Les parties prenantes sont plus engagées simplement parce qu’elles perçoivent les bénéfices du projet plus tôt et plus souvent.
Tandis que cette approche est relativement évidente pour certains projets, d’autres, comme la mise en œuvre d’un gros ERP, peuvent être plus difficiles. Ces projets plus compliqués et vastes devraient être planifiés par phases, avec des fonctionnalités délivrées à intervalles réguliers. Pas plus que neuf mois devraient se passer entre l’expression des exigences et la livraison de la fonctionnalité! La planification d’un projet être difficile de cette façon, mais cela peut être fait et les bénéfices à le faire le valent bien. Ces bénéfices incluent :
Éviter les problèmes de changements de priorité business ou de manque « de continuité d’attention » de l’entreprise. Les projets seront plus probablement complétés quand la valeur business est délivrée à intervalles réguliers.
Introduire le changement dans la communauté des clients avec une ampleur et une allure qu’ils puissent absorber. Les projets longs qui produisent de gros livrables présentent une somme considérable de changements d’un seul coup. Ce seul fait peut créer des problèmes d’assimilation du changement pour les utilisateurs finaux, peut renforcer des problèmes de processus business et générer un mécontentement. Gardez les changements petits, livrez-les régulièrement et vous ferez plus probablement des clients heureux.
Garder la fraîcheur des exigences business. Des projets plus longs ont souvent des problèmes avec un périmètre et des besoins changeants tout simplement parce que le business que le projet supporte ne reste pas statique. C’est un monde business qui bouge rapidement et montre peu ou pas de signes de ralentissement. Des projets plus longs délivrent simplement sur des exigences éventées ou dépassées. Maintenir un cycle (ou des phases) court de l’expression des besoins à la livraison et vous aurez moins de problèmes d’obsolescence et de volatilité des exigences.
Managez et Comprenez la Longueur « du trajet »
Les triples contraintes de projet sont établies tôt dans le projet. Bien sûr, elles devraient changer comme on découvre de plus en plus le détail du projet et la solution exigée. Malgré cela, certains des paramètres généraux pour le projet sont établis très tôt. Une période satisfaisante pour la livraison – la considération sur l’ampleur du changement et la complexité du projet, est décidée tôt en tant que partie des triples contraintes. Cependant, ceci est souvent oublié quand les demandes de changement sont traitées, les ajustements de priorité causés par des changements business et d’autres événements inattendus sont rencontrés par l’équipe de projet. Nous avons une tendance à nous concentrer sur le micro niveau de changement et à oublier la macro période du projet – ce que nous avons à l’origine utilisé pour justifier le lancement du projet! Manager le niveau macro période du projet exige la chose suivante :
Pendant les premières étapes de planification du projet, mettez une durée désirable pour le projet et « une durée au risque acceptable ». La durée au risque acceptable est une durée qui est plus longue que celle prévue à l’origine, cependant elle est toujours acceptable pour les clients business et l’équipe de projet. Cette durée de risque devrait considérer le degré de volatilité business, le paysage compétitif de votre secteur d’application et la capacité à conserver les membres d’équipe avec les bonnes compétences sur la durée projetée.
Se focaliser sur l’impact à long terme d’accepter des changements au projet. Un processus de management des changements standard devrait être exigé sur tout projet. À un certain point cependant, idéalement quand on s’approche « de la durée de risque acceptable », la portée entière du projet devrait être réévaluée. Tous les changements qui ne sont pas achevés devraient être reconsidérés et priorisés. Le périmètre – au macro niveau – peut alors être évalué pour assurer que le projet reste dans une période acceptable.
Le tunnel « sombre et tortueux » est un endroit solitaire pour un chef de projet. La planification diligente, le management attentif des changements et un œil sur la vue d’ensemble, en plus des procédures de management de changement typiques peuvent maintenir votre projet en vie et vos clients heureux. Et ce n’est pas mal pour votre santé mentale personnelle non plus!
Et vous êtes peut-être déjà tout seul, sur une île déserte, conversant avec vous-même.
C’est étrange parce que vous pensez que d’autres sont encore là, à écouter attentivement ce que vous leur racontez pendant cette conférence téléphonique.
Mais ils sont partis.
Oh, ils n’ont pas raccrochés, sinon vous auriez entendu le petit ding-dong.
Mais, certains on posé le combiné et coupé le micro pendant qu’ils font du ménage dans leur messagerie électronique. D’autres sont sortis de leur bureau pour aller discuter à la machine à café. Certains jouent à des jeux vidéos, d’autres relisent un document ou consultent les informations sur Internet, d’autres peaufinent une présentation ou finalisent un rapport, d’autres lisent leurs blogs favoris…
Ceci se produit souvent pendant les téléconférences longues et ennuyeuses. Et je suis persuadé que vous l’avez-vous-même déjà fait. En particulier si la réunion dure des heures, ou bien se répète chaque semaine, où encore porte sur un sujet de moindre importance ou intérêt pour vous.
Il est curieux de voir que malgré la pression toujours plus forte d’obtenir plus de chaque minute de chaque personne, il est parfaitement toléré de leur demander ou même d’exiger qu’elle perde des heures dans de mauvaises réunions.
Que faire pour sensiblement améliorer votre téléconférence ?
Une téléconférence ne devrait pas excéder une demi-heure. Plus longtemps et les gens partent, physiquement ou mentalement.
B) Faire petit.
Une téléconférence ne devrait pas avoir plus de huit participants. Plus de 8 est la garantie que plusieurs seront des spectateurs muets.
C) Faire simple.
Une téléconférence devrait porter sur un unique sujet qui peut effectivement être traité par téléphone. Les problèmes plus complexes nécessitent une vrai rencontre en face à face.
Et il conclut en nous rappelant que toute réunion est une activité business qui devrait apporter un vrai bénéfice.
Pour ma part, je pense comme Steve que faire court et limiter les participants aux seules personnes directement impliquées par l’objet de la réunion est effectivement une excellente base de départ pour avoir une réunion efficace.
Cependant, je crois qu’il faut également prendre en compte l’objectif de la téléconférence. Ce peut-être par exemple du partage d’informations, du « team building » pour une équipe géographiquement distribuée, de la résolution de problème, un statut d’avancement, une demande de décision…
Cette clarification de l’objet de la réunion conduit à un nécessaire travail préparatoire sur l’agenda et le contenu. L’agencement des sujets peut alors aider fortement à structurer et améliorer la conférence. On peut par exemple envisager de faire intervenir plusieurs personnes à tour de rôle sur différents sujets pour donner du rythme et pour doper leur attention.
De plus, les outils collaboratifs de partage en temps réel de documents sur lesquels travailler encouragera les participants à suivre la progression sur écran, au lieu de faire d’autres choses.
Coté animation, je reste convaincu qu’il faut s’attacher à démarrer à l’heure prévue (+ 5 minutes de courtoisie) même si tous les protagonistes ne sont pas encore connectés. Et, surtout, ne pas répéter ce qui a déjà été dit pour les retardataires. Seulement leur préciser où nous en sommes de l’agenda (sinon vous risquez fort de vous trouver dans la situation de cette vidéo). Et puis, faire attendre les personnes qui sont à l’heure ou répéter ce qui a déjà été dit est un manque de respect pour leur temps et un coût pour la société. Rappeler aux participants l’agenda et l’heure de la réunion 24 heures à l’avance peut être utile, en particulier si ils ont à réaliser un travail préparatoire : lecture de document, analyse, recherches…
Enfin, le complément de l’image grâce à la visioconférencepermet d’avoir de bien meilleurs échanges et permettent de traiter certains problèmes plus complexes et plus sensibles grâce à la sensation d’une « vraie » rencontre en face à face.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Analyse des besoins : Tout semble si simple au départ. Mais ensuite, que vous construisez un nouveau système à partir de zéro ou achetiez un système et l’adaptiez pour répondre au modèle économique spécifique de société, vous devez traverser une phase d’analyse des besoins. Ce n’est pas tâche facile. L’estimation budgétaire peut aller dépasser des sommets et c’est assez dur. Mais la question la plus difficile est comment vous assurez que le nouveau système fait ce à quoi les utilisateurs (et bien sûr les clients) s’attendent. Si vous remplacez un système existant, le nouveau système devrait faire que le système ancien fait au moins aussi effectivement et efficacement, sinon mieux. C’est un énorme défi.
Voici une douzaine de recommandations pratiques qui seront utiles pendant cet exercice :
1. Ne pas bousculer cette étape
Des études innombrables ont montré que la collecte des besoins est l’étape la plus importante dans le Cycle de vie de Développement de Logiciel. Il est beaucoup plus onéreux de réparer une erreur sur le besoin qu’une erreur de programmation. Mais d’une manière ou d’une autre chacun semble croire qu’un document de spécification des exigences est la partie la plus facile à réaliser et la partie de conception/développement la plus difficile. Cela ne peut pas être vrai. Personne n’a jamais construit une bonne structure sans bonnes fondations. Assurez-vous que vous prenez du temps pour entièrement rassembler les besoins et les analyser en profondeur. Budgétisez le temps suffisant pour rassembler et analyser les besoins avec suffisamment de détail. Ne bousculez pas cette étape à moins que vous ne vouliez enterrer le projet.
2. Détails. Vous ne pouvez pas en avoir trop
Les besoins décrits sur une seule ligne de mots (« one liners ») n’aident pas à concevoir et développer un système. Mais c’est souvent ce que vous obtenez. Et chacun l’interprétera en fonction de leur propre connaissance et expérience. Vous ne pouvez pas acheter d’assurance contre une mauvaise interprétation. Vous devez obtenir une bonne vue d’ensemble, mais vous devez aussi entrer dans les détails infimes. Demandez des détails, même quand la question semble mineure. Vous pouvez y découvrir quelque chose de vraiment critique.
3. Comprendre le business, pas les besoins exprimés
Ne regardez pas de besoin en isolation. Les besoins existent pour supporter une exigence business. Parvenez à connaître ce qu’est ce business- tout aspect de celui que vous essayez de supporter. Une fois que vous avez cela, les liens entre les diverses pièces du puzzle commencent à apparaître. Les besoins tombent simplement à leur place. Vous savez ce qui est critique et pourquoi. La bonne solution apparaît quand vous retournez à la planche à dessin.
4. Tout documenter
Pendant que vous rassemblez les besoins, vous obtenez une quantité énorme de données, souvent sous formes disparates. Des textes, des feuilles de tableur, des présentations PowerPoint, des graphiques et images. La liste est infinie. Documentez, indexez et conservez chaque morceau d’informations que vous rencontrez par hasard et utilisez un bon outil logiciel. Demandez à chacun dans le projet de tout documenter dans une base de données centralisée, pas sur leurs bureaux. Gardez-les à jour. Il n’y a aucun doute que le contexte et la compréhension qui vient avec un document ne peut pas toujours être traduit en besoins. Mais, quand une personne quitte le projet ou l’organisation, vous ne pouvez pas vous permettre de perdre quoi que soit des informations qui existent dans ses cellules grises. Documentez. Quelqu’un regardant les besoins n’aura pas besoin de réinventer plus tard ce que l’on connaît déjà.
5. Impliquer les utilisateurs. Les utilisateurs réels
Les utilisateurs réels sont ceux qui savent le mieux, mais souvent ce sont leurs patrons qui viennent aux réunions avec les analystes (« busines analysts ») et l’équipe de développement. Les hommes en costumes sombres ont probablement la vue d’ensemble et peuvent probablement définir les besoins plus clairement, mais les utilisateurs réels du système sont ceux qui connaissent les éléments clefs et les points de douleur. Impliquez-les chaque fois que vous le pouvez. Particulièrement quand la rentabilité et les flux de travail qui sont clefs au succès du système.
6. Aller les voir travailler
Souvent ce que disent les utilisateurs n’est pas ce qu’ils veulent dire en réalité. Les raisons sont multiples. Ce pourrait être à cause d’un écart de communication, parce qu’ils supposent que de certaines choses sont juste trop basiques pour être mentionnées, ou simplement oubliées. Observez-les dans l’action. Ne vous contentez pas de regarder, observez! Vous serez agréablement surpris des résultats. Le flux de processus est souvent le facteur le plus critique au succès du système en construction. Malheureusement la plupart des collectes de besoins se passe entre les quatre murs d’une salle de conférence ou sur des conférences téléphoniques, pas sur place. Voyez les choses dans l’action, pas dans votre imagination. Souvent, j’ai constaté qu’une heure passée sur place valait plus qu’un jour entier de discussion.
7. Chercher le « chemin malheureux »
Trop souvent nous finissons par construire un système qui traite parfaitement bien le flux normal. Chacun peut vous dire ce qu’est le « chemin heureux »; mais seuls ceux qui utilisent le système dans un contexte business réel peuvent vous dire tout ce qui peut mal tourner. Et si vous ne construisez pas votre système pour traiter les choses qui « peuvent aller mal », vous avez construit un château de cartes. Ne demandez pas simplement aux utilisateurs le « chemin heureux » », encouragez les à vous parler du « chemin malheureux ». Mais souvenez-vous; demandez aux vrais utilisateurs.
8. Aller dans les coulisses
Avec des systèmes multiples mis en œuvre dans l’environnement de travail de nos jours, souvent les utilisateurs ne savent plus quel le système fait quoi. C’est totalement transparent pour eux. La transparence est bonne du point de vue des utilisateurs, mais pas pour ceux qui cherchent à construire un nouveau système. Les utilisateurs vous diront ce qu’ils pensent que fait leur système existant. Efforcez-vous de connaître la portée du système que vous essayez de construire ou remplacer. Impliquez les gens techniques qui peuvent fournir ces informations pour éviter de devoir refaire.
9. Trouver les documentations
Cherchez le manuel système et guide utilisateur. Vous en trouverez beaucoup prenant la poussière dans un coin oublié. Alors que les utilisateurs peuvent vous parler de choses qu’ils font souvent, il y a des choses dont ils ne se rappellent pas – ou ne comprennent pas. Un document correctement approuvé peut être une mine d’or d’informations. Il pourrait vous dire non seulement ce que le système fait, mais aussi pourquoi. Le pourquoi peut être décisif quand vous devez prendre certaines décisions sur inclure ou pas une fonctionnalité spécifique dans le nouveau système.
10. Construire un nouveau système, ne pas copier l’ancien
Souvent les utilisateurs veulent que le nouveau système fasse les choses exactement de la même façon que le système précédent. Les personnes au sommet seraient aussi heureuses puisque cela diminuerait le coût de formation et éviterait des erreurs. La plate-forme technologique que vous utilisez pour le nouveau système pourrait être bien meilleure, mais faire les choses d’une manière peu familière aux utilisateurs. Obtenez l’engagement de la direction. Faites que les utilisateurs sachent qu’il va être différent. Après tout, vous construisez un nouveau système, vous ne produisez pas une copie de l’ancien !
11. Construire des besoins ou des limitations ?
Il n’est pas rare que des utilisateurs demandent quelques fonctionnalités dans le nouveau système basées sur ce que fait leur ancien système. Ils peuvent sincèrement croire que c’est le besoin business alors que c’est en réalité une limitation du système existant. Personne ne se rend compte que c’est une limitation parce que c’est ce qu’ils ont toujours fait. Ne finissez pas par intégrer ces limitations.
12. Voir les rapports et les gens qui les utilisent
Vous pensez que les rapports sont la partie plus facile ? Repensez-y. Ce sont les rapports qui fournissent une vue de ce qui se passe dans l’organisation aux gens qui prennent toutes les décisions critiques. Faites une gaffe sur les rapports et vous avez fait tout ce qu’il faut pour la perte de l’organisation. À propos, l’organisation peut avoir un stock énorme de rapports qui sont produits dans le système existant, mais quelqu’un les utilise-t-il ? La construction d’un nouveau rapport coûte de l’argent. Pas seulement l’effort premier de les construire et les tester, mais ensuite le coût pour l’impression, la diffusion, le stockage et la destruction. Et oui, vous augmentez aussi votre empreinte carbone. La diminution du nombre de rapports de moitié quand un nouveau système est introduit n’est pas rare du tout. Regardez-le comme une opportunité de nettoyer l’inventaire de rapports.
La bonne équipe avec le bon niveau de temps investi peut être la clé du succès de la phase la plus critique de construction d’un nouveau système. Prenez votre temps, tout à fait littéralement. Cela peut faire la différence entre un projet réussi et un échec.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Apprendre à manager les parties prenantes avec un simulateur pédagogique
« Simulateur pédagogique » ? Au féminin ça ferait « simulatrice attentionnée » par exemple… ça me tente de m’engouffrer dans cette expérience électronique et virtuelle d’un mode d’apprentissage décalé.
Rendez-vous ce soir 20h pour tester le système. Tout est prêt : Exécutable installé, documentation imprimée, connexion Skype vérifiée pour les instructions de démarrage, quantité modérée de Chimay rouge à portée de main…
Du moment ludique aux bonnes résolutions en passant par … le coup de bambou.
C’est parti pour un projet simple… en apparence
Le duel homme-machine commence. Tel un Kasparov au cœur d’une partie d’échecs face à un adversaire capitalisant l’expérience de ses meilleurs coups, l’intelligence de modélisateurs aguerris et la puissance de calcul des processeurs.
Je suis face à une modélisation numérique des parties prenantes autour d’un projet. Me voici confronté au défi où le chef de projet que je suis, formateur qui plus est, doit montrer ses aptitudes à comprendre le modèle, à « déjouer » les pièges et à me montrer au moins aussi malin que ses concepteurs. Bel enjeu.
J’entre dans le sujet avec délectation. On me confie l’avant-projet de construction de la mine de cuivre de Baraka, au Venezuela.
Noms exotiques des parties prenantes autochtones, décors et bruits de la jungle endémique, et la quadrature du cercle à résoudre. Tout est là. J’ai pour mission de réconcilier les intérêts de 12 parties prenantes comme mon patron, le ministre de l’économie, l’actionnaire de ma société, le délégué syndical des employés ou l’écologiste de service…
De quoi titiller mon sens du défi.
Confronté à des choix, mes décisions prennent tout leur poids
La lettre de mission m’est envoyée, et à partir de ce moment tout va très vite. Je dois prendre des décisions sur la configuration du projet. Si je choisis une mine à ciel ouvert, c’est moins onéreux qu’une mine enterrée : l’actionnaire jubile. Mais ce choix implique de détruire la forêt des arbres rouges, et l’écologiste saute au plafond. Pas grave, ça lui fait du sport ? Peut-être, mais le client qui a choisi une politique franchement « green » voit d’un mauvais œil cette émergence contestataire sur les choix du plan de mon projet.
Parallèlement à ces choix techniques, je peux (et je dois, évidemment) communiquer avec tous ces gens. Et un peu comme dans la vraie vie, le raccourci communiquer=informer ne fonctionne pas. Il faut que je demande à chacun ses critères de réussite du projet, mais aussi les personnes sur lesquelles va se baser son opinion. Et comme si ça ne suffisait pas, je peux (et encore une fois, je dois) aller transmettre auprès des uns l’opinions des autres qui comptent pour eux.
En cours de route, je peux voir comment évolue la satisfaction des parties prenantes sur mon projet, l’impact des choix (catastrophiques) que j’ai tenté de faire, et comment j’ai réussi à redresser la barre au fur et à mesure…
Quel rapport avec la vraie vie ?
Évidemment, je n’ai jamais eu de projet de ce niveau d’enjeu avec autant de parties prenantes…
Quoi que.
Peut-être l’enjeu financier n’était pas si grand, mais la quantité de parties prenantes ?
Mon commanditaire interne, mon chef, mon sponsor, le DSI, le PMO, le prestataire informatique (et 10 informaticiens derrière), le fournisseurs de hardware, le logisticien tiers utilisateur, mon client bénéficiaire externe (et sa déclinaison politique, managériale, technique, utilisatrice), mon client financeur, l’acheteur client, le commercial grand compte qu’on m’avait collé pour les rendez-vous client, l’association RosettaNet, les 3 key-users (et 40 futurs utilisateurs derrière), la juriste, les consultants et les experts… et ceux que j’oublie.
Sapristi ! J’ai dépassé les 12… sans évidemment compter « ceux qui sont derrière ».
Soudain, le coup de bambou !
Pas une fois, dans ce projet « complexe », je n’ai élaboré un Plan de Management des Parties Prenantes (PMPP), cherché à formaliser les relations « cachées », les influences sous jacentes. Jamais je ne me suis dit : « celui-ci préfère que je passe le voir tous les mois dans son bureau, celui-là veut un mail par semaine et dernier doit être tenu informé par téléphone avant chaque rendez-vous client. »
Oui, j’ai fait comme j’ai pu. Oui, j’ai écouté, répondu, informé, demandé… Mais aucune méthode. Aucune systématicité. Aucune modélisation de cet environnement, certes complexe, mais pas impossible.
Cette carence n’explique pas toutes les difficultés auxquelles j’ai été confronté. La mise en place d’un plan de management des parties prenantes béton n’aurait pas forcément raccourci sa durée de 50%, d’un an ou augmenté le taux de satisfaction.
On pourrait dire que j’ai fonctionné à l’intuition, avec un bon relationnel, une attention aux personnes… et que cela suffit.
Quoi que.
Il me faut réagir, ce qui est plus difficile sans anticipation
Piloter la satisfaction de 3 ou 5 parties prenantes, cela peut se faire à l’intuition. On pourrait même envisager que dans certains cas, élaborer, modifier et suivre un PMPP fabrique de la charge et diminue son écoute et son attention.
Mais quand on dépasse ces 5, que des intérêts sont très divergents, que les cultures sont inhabituelles, que les réseaux sociaux sont complexes, intégrer un PMPP dans son PMP (Plan de Management de Projet) est fondamental.
J’irai même jusqu’à dire que pour une dizaine de parties prenantes, cela devient l’enjeu principal :
1° Lister les parties prenantes
2° Comprendre leur attentes en terme de communication, leurs critères de réussite, leurs relations sociales et leur mode de fonctionnement en général
3° Cartographier tout ça dans une matrice lisible
4° La décliner au cours du temps
5° Réaliser ce PMPP (Communiquer !), et le mettre à jour.
Soulagement ? ce n’était qu’un entraînement…
J’ai plutôt bien réussi la simulation. Ouf : l’honneur est sauf.
Mais à la réflexion, je me demande si je n’aurais pas préféré faire la simulation avant mes projets et me planter comme un bleu.
Ça m’aurait peut-être aidé à obtenir une adhésion et une satisfaction supérieure de mes parties prenantes « réelles », dans mes vrais projets.
Et maintenant, que diriez-vous d’une simulation sur une thématique du management de projets ?
En faisons-nous souvent beaucoup trop pour donner une bonne première impression à notre chef, nos collègues, nos clients? Voici un article qui donne à réfléchir à ceux qui se plaignent de de voir être disponibles 24 heures sur 24 et 7 jours sur 7 pour leur boulot.
Vous commencez à travailler pour quelqu’un de nouveau et vous voulez faire bonne impression. Peut-être commencez-vous à garder votre BlackBerry sur vous partout et à leur répondre à toute heure de la nuit et du week-end. Chaque fois qu’ils vous envoient quelque chose, vous leur répondez que vous soyez ou pas en service.
Avec le temps vous constatez que les personnes avec lesquelles vous travaillez vous ennuient. Qu’est-ce qui se passe avec eux ? Ils vous appellent ou vous envoient un SMS à toute heure du jour et de la nuit. Quand vous ne répondez pas tout de suite, ils continuent à vous envoyer message après message. Vous devenez de plus en plus irritable. Est-il insensé de vouloir simplement quelques heures pour vous ?
À qui la faute ? C’est votre faute, n’est-ce pas ? Vous désiriez tant faire une bonne première impression que vous avez oublié que la définition des attentes est une voie à double sens. Vous avez maintenant instauré la perception du fait que vous êtes disponible 24×7. Vous ne l’avez pas nécessairement demandé. Mais, dans les faits, vous l’avez démontré par votre empressement à répondre à des communications professionnelles toute la nuit et tout le week-end.
Quand vous travaillez avec quelqu’un de nouveau ou démarrez sur un nouveau projet, vous aimez évidemment faire une bonne première impression. Mais parfois vous produisez un effort Herculéen. Autrement dit, vous travaillez si durement que vous vous tuez littéralement au travail pour faire cette bonne première impression. Vous faites quelque chose que vous ne voulez pas vraiment faire sur une base régulière. Puis, vous êtes crevé. Vous pouvez devenir amers. Peut-être commencez-vous même à avoir envie de jouer les victimes ou les martyrs. C’est vraiment votre faute; vous avez pris la décision de violer vos propres limites.
Soyez honnête sur vos limites.
Si le dimanche est le jour de la famille, le dimanche est le jour de la famille. N’acceptez pas un boulot où quelqu’un vous fait asseoir et vous dit qu’ils font des tonnes d’heures supplémentaires chaque week-end.
A utiliser avec parcimonie. Si votre patron vous envoie quelque chose et c’est important et urgent et c’est rouge et ça flashe et tout cela, prêtez-y l’attention. Mais toutes les personnes qui travaillent pendant le week-end ne s’attendent pas à ce que vous fassiez de même.
Si je suis votre nouveau manager, directeur, vice-président, chef de projet, chef d’équipe, superviseur, et que je vous vois travailler de longues heures, je pourrais simplement supposer que c’est votre manière de fonctionner. Je pourrais supposer que vous vivez pour le travail. Je vais même le prendre pour acquis; je vais m’y attendre de vous tout le temps. Cela ne signifie pas nécessairement que je vais récompenser votre comportement. Peut-être ou pas du tout.
Dans votre hâte à créer une première bonne impression ne faites pas quelque chose que vous n’êtes pas enclins à faire sur une base régulière.
Sachez ce que vous voulez, présentez-vous comme qui vous êtes vraiment, soyez clairs sur comment vous voudriez être traités et soyez honnêtes sur ce qui fonctionne ou pas pour vous.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Un ami m’a invité à lire cet article centré sur la nécessité de connaissances ou au moins de compréhension des finances de base pour tout informaticien. Je pense qu’il s’applique également à la profession de chef de projet. Même si nous ne sommes pas tous très versés ou fanas des aspects financiers, ceux-ci sont souvent au cœur du sujet pour déterminer la poursuite ou l’arrêt d’un projet, sa réussite ou son échec final. Un cours « finances pour non financiers » est d’ailleurs en général très apprécié comme j’ai pu le constater dans plusieurs entreprises.
Vous pouvez avoir les meilleures équipes et respecter tous vos jalons, mais en fin de compte, les projets vivent ou meurent par leurs données financières.
Avec un budget informatique moyen s’établissant à 2-8 % de revenu et 30-50 % de capital investi, on penserait logiquement que, en moyenne, l’informaticien a, sinon une connaissance robuste des données financières de l’informatique, au moins une compréhension raisonnable de l’essentiel, pour qu’il puisse voir comment ses activités quotidiennes contribuent à ces chiffres.
Eh bien, réfléchissez-y à nouveau. Seul le sommet de la direction informatique comprend vraiment ce que les chiffres représentent – ou plus précisément, supposent représenter parce que, comme nous verrons plus loin sur, il y a une marge significative d’erreur. Le reste, qui signifie la grande majorité du service informatique, a peu d’idée comment leur travail quotidien impacte les résultats financiers de la société. Ils ne s’en soucient probablement pas particulièrement, pas parce qu’ils ne sont pas des professionnels, mais parce qu’ils ne le considèrent pas comme une partie de leurs responsabilités. Ils sont là pour faire l’analyse, le développement, le support ou autres ; les finances sont le travail de leurs managers – ou pour les comptables du département financier.
Et pourtant, c’est le travail quotidien de ces personnes, construit sur des corrélations complexes entre des équipes de spécialistes, qui font ces résultats. Comment des personnes qui estiment que les données financières informatiques ne font pas partie de leurs responsabilités peuvent-elles fournir les informations précises qui seront en bout de ligne converties en données financières de l’ordre de 2-8 % du revenu et 30-50 % des investissement de capitaux ?
La réponse, bien sûr, est qu’ ils ne le peuvent pas. Par exemple, un sondage de PSB Research en mai 2009 auprès de décideurs de l’informatique a constaté que presque les trois quarts d’entre eux estiment leur marge d’erreur de 5-20 % dans leurs coûts réels, tandis que seulement 12% auraient une marge d’erreur de moins de 5 %. Pour un $100m de budget informatique, cela signifie que les chiffres pourraient être erronés de 5 à 20m pour trois sur quatre de toutes les sociétés interrogées. Autrement dit, il pourrait être de $80m comme de $120m – ce qui n’est pas exactement de la menue monnaie.
Le sondage confirme simplement ce que la plupart d’entre nous soupçonnent de toute façon. Au cours de beaucoup de mes années dans l’industrie, dans des services informatiques et aux ventes de logiciels, j’ai régulièrement entendu dire que les gens – incluant des cadres supérieurs – admettent ouvertement qu’ils ne savent pas la différence entre dépenses d’investissement et opérationnelles (opex) ! Ou bien, ce qu’est la dépréciation et comment elle s’applique aux systèmes d’information. Ou encore la différence entre un compte de résultats et un bilan. Ou comment les provisions augmentent l’exactitude du rapport mensuel. Ou la différence entre un budget et un prévisionnel. Pour voir comment vous vous en sortez sur l’essentiel des données financières, prenez ce rapide test 1-minute survey et voyez les résultats. Vous pouvez aussi passer à travers le IT Financials Glossary et tester votre compréhension de l’essentiel [de la terminologie financière anglo-saxonne].
Ce ne serait pas si terrible si les contrôleurs financiers jouaient leur rôle de gardien et de protecteur et étaient capables de capturer de telles erreurs. Malheureusement, ce n’est pas toujours le cas. Beaucoup de sociétés souffrent du dilemme classique d’informaticiens ne connaissant pas assez la finance et de financiers ne connaissant pas assez l’informatique. Donc, l’informatique donne des chiffres à la finance, qui doit souvent les prendre pour argent comptant. C’est aussi vrai pour les budgets que pour les données réelles. Ces mêmes chiffres sont alors parfois refacturés en interne au business, qui pourrait avoir peu d’idée de ce qu’ils payent puisqu’ils doivent à leur tour les prendre à leur valeur nominale.
OK, et alors ? Qui s’en soucie ? L’informatique est de la technologie et de la livraison et direction de systèmes pour le business, n’est-ce pas ? Depuis quand les finances font-elles partie de la description de poste ? Eh bien, elles pourraient ne pas faire partie de la description de poste, mais les chiffres pilotent tout. Vous pouvez assembler les meilleures équipes de projet, atteindre tous vos jalons et produire tous vos livrables, mais en bout de course, vos projets et leurs applications informatiques résultantes vivent ou meurent selon leurs résultats financiers. Et ceci est vrai de la planification d’investissement et prévisions budgétaires à la gestion des coûts et leur imputation :
Planification d’investissement : de pauvres pratiques financières peuvent aboutir aux choix de mauvais projets d’une perspective justification business (« business case ») (lisez : le projet va probablement échouer malgré les meilleurs efforts de chacun)
Prévisions budgétaires : des budgets de projet peu réalistes, par définition basés sur des suppositions et des estimations, deviennent souvent gravés dans le marbre, au lieu de se développer naturellement par prévision mensuelle. Pour la plupart des projets, c’est souvent le budget et pas les dépenses, qui sont erronés.
Management des coûts : une attention insuffisante aux données financières aboutit à une énorme quantité de suivi et de rapports frustrants et sans valeur-ajoutée, laissant les projets et applications informatiques exposées à des réductions de coûts par défaut.
Imputation : les clients business ont souvent peu d’idée de ce qu’ils payent puisque le projet informatique et les responsables d’applications sont d’habitude incapables de comprendre leur difficultés financières, aboutissant à un focus sur les coûts plutôt que sur la valeur.
Pour conclure, tout le personnel informatique – et pas seulement la direction – doit augmenter sa compréhension financière générale, parce qu’en fin de compte ce sont les actions de chacun qui contribuent à l’exactitude, la ponctualité et la crédibilité des chiffres totaux.
Cela exigera la mise en œuvre de processus financiers de base pour les prévisions budgétaires et le management des coûts dans une structure de management de projet qui va au-delà de la seule livraison du projet. Au moment où la balle est passée aux équipes de support, la référence de base financière est d’habitude à peu près établie et peut seulement augmenter après cela.
Une constante qui restera est le besoin de communication efficace peu importe quels médias l’équipe utilise. Au milieu des années 1990s, j’avais commencé à manager des équipes virtuelles. Y compris dans mon engagement volontaire de leadership, la plupart de mes activités avec PMI ont été conduites dans un espace virtuel. J’ai dû rapidement développer des compétences dans la communication qui différaient beaucoup des interactions en face à face.
Considérons une instruction unique comme : “j’ai reçu votre produit et ai quelques questions à clarifier.” Si le chef de projet sort d’une réunion telle que celle j’ai décrite, voici comment il pourrait recevoir le message : “j’ai reçu votre produit et il y a beaucoup de problèmes qui exigeront des changements. Je vous contacterai par courrier électronique plus tard avec tous mes commentaires et retours d’information.”
DantotsuPM.com 