quelles sont les clés du succès des leaders ?

How centered leaders achieve extraordinary results un article de McKinsey Quarterly

J’ai bien aimé dans cet article les cinq compétences que McKinsey a identifié comme étant au cœur du leadership:

  1. trouver et donner du sens au travail
  2. convertir des émotions telles que le stress et la peur en opportunités
  3. savoir tirer partie de ses connections et de sa communauté
  4. agir face aux risques
  5. 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

comme je l’avais indiqué dans un article précédent sur 7 compétences de leadership pour les chefs de projet.

objectif butEt, 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.

cible
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

J’avais dans l’article sur les compétences en leadership pour les chefs de projet mis en avant les bénéfices de savoir :

  • faire et démontrer confiance en l’équipe
  • déléguer de vraies responsabilités
  • 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.

supporterLe 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é.

JaponPar 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.

CSP Formation
Partenaire de DantotsuPM

partage d’expériences en management de portefeuille de projets à Monaco

PMI France-SudPMI 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.

portfolio management 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.

CSP Formation
Partenaire de DantotsuPM

les réunions de démarrage de Projet

Project Kickoff Meetings de Philip Diab

project launch kickoff lancement projetBien 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 :

  • commentairesLa 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 :

  • à retenirRevoir 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.

CSP Formation
Partenaire de DantotsuPM

le bureau ne serait pas le bon endroit pour travailler

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…

CSP Formation
Partenaire de DantotsuPM

comment faire approuver votre idée, proposition ou recommandation

How to Get Your Idea Approved de Amy Gallo

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.

CSP Formation
Partenaire de DantotsuPM

Maîtrises ?

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 »

organisation projet initialeJe 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 !

organisation projet finaleDans 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.

CSP Formation
Partenaire de DantotsuPM

<!–[if !mso]> <! st1\:*{behavior:url(#ieooui) } –>

Maîtrises ?

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 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.

La liste des choses à NE PAS faire

The Not-Do List: 9 Things You Need To Stop Doing sur le blog Lifehack.

choses à faire todo listNous 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é.

Lisez la stratégie #6 sur 13 Strategies To Jumpstart Your Productivity pour plus de détails sur la règle des 80/20.

2. Répondre à tous les emails (ou appels et messages)

nouveau messageJ’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.

unclear goals or direction7. 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.

CSP Formation
Partenaire de DantotsuPM

Réaliser une présentation aux parties prenantes du projet : 10 astuces pour une communication efficace

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. »

need for budget - besoin de budgetMon 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 ».

Voici la traduction de l’article de Ty Kiisel:

Presenting to Project Stakeholders: 10 Tips to Effective Communication

capture their attentionMaintenir 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.)

faire une presentation4.      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 ?

CSP Formation
Partenaire de DantotsuPM

comment éviter « l’effet tunnel » en management de projet

« 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.

Avoiding the « Dark Twisty Turn-filled Tunnel Syndrome »

(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é.

long tunnelLes 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 :

  • attentifÉ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 :

  • vue à long termePendant 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!

Où sont les participants ?

seul au mondeLa réunion a commencée depuis 10 minutes.

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 ?

Steve Kay, dans son billet “Do You Know Where Your Attendees Are?”, propose 3 conseils.

A) Faire court.

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.

à l'heure ponctuel ponctualité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érence permet 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.

CSP Formation
Partenaire de DantotsuPM

en matière d’élaboration des besoins: vite fait = mal fait (« exigences précipitées, projet enterré »)

La collecte des besoins est l’étape la plus importante dans le Cycle de vie de Développement Logiciel.

vite fait rapide courir vitesseRequirements Hurried . . . Project Buried (exigences précipitées, projet enterré) de G Chandrashekar

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.

détailler2. 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.

ecrire documenter4. 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.

designeur au travail6. 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.

copier plagier10. 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.

 

CSP Formation
Partenaire de DantotsuPM

 

Apprendre à manager les parties prenantes avec un simulateur pédagogique par Jean-Baptiste Jourdant de CSP Formation

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 ?

Jean-Baptiste JOURDANT, Chef de projets chez CSP Formation

CSP Formation
Partenaire de DantotsuPM

 

soyez honnête sur VOS limites

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.

Be Honest abour YOUR Boundaries posted by Margaret in Untagged

Est-ce que cela vous ressemble ?

vouloir tout faireVous 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.

CSP Formation
Partenaire de DantotsuPM

les compétences financières sont cruciales pour les chefs de projet

bilan financierUn 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.

IT financial skills – mind the gap! article de Michael Gentle

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].

sécuriser protéger coffre fortCe 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.

Michel Gentle est un consultant informatique de données financières et l’auteur de « An Introduction to IT Project Financials – Budgeting, Cost Management and Chargebacks ». Pour d’autres articles sur ce sujet, visitez www.itprojectfinancials.com.

CSP Formation
Partenaire de DantotsuPM

Who else wants to better prepare for being a speaker at a large conference ? (some more tips)

salle de conférenceHello, thanks to the numerous feedbacks that readers sent me for the post « You’ll be a speaker at a large conference: How to best prepare » , I prepared this follow up message to summarize their wise advices for the benefits of all.

Applicability of the advices:

  • Big or little conference, ‘small’ internal presentation or not – most guidelines apply everywhere.
  • Any ‘public talk’ is an opportunity to get comfortable with the techniques. That way you’ll be ready when that large conference arrives!

Preparation:

  • A difference between usual presentations and big events and conferences is the time between when you know you have to talk and the date of the speech, and the associated deadlines
  • Another difference for large events is the distance with the audience – both physically and mentally and the supporting material that you have to provide. Take the time to find out what the audience cares about and be flexible enough to change. It’s never about you, it’s always the audience, if they do not hear what you are saying it’s your problem not theirs. Check to make sure you are on the same wavelength.
  • Anticipate and plan your communications with the people that you need to agree with (the external communications department of your company for instance).
  • Always be clear on cost & impact, i.e. what is at stake? Do not inflict unnecessary stress on yourself.

In practice, a few tips:

  • I always start with « my name is ………………… and I love my job ». If you are not passionate about what you do, why should the audience?
  • trois choses, 1,2,3I have a slide that says here are the three things I would like you to walk away with. Refer back to the three things in your closure.
  • I would add that no matter what, if you make a mistake or if you have a blank (and it does happen even to the most prepared speaker) take a deep breath.  To the speaker, it will seem forever, to the audience, it will just give them time to mull over what you said before. This gives the speaker a rest to get his/her bearings back.  Light humor always helps also.
  • Test the projections on a very large screen. Images that look acceptable on a computer screen or a smaller projector can look pixelated when projected to a convention wall.
  • If you have an assistant, make sure that you have worked out the signal to move slides BOTH forward and backward.
  • Make sure you utilize the restroom BEFORE they attach the microphone.
  • Join Toastmasters so you can practice your speech before a live audience. Try out anything that you are uncertain about at a Toastmasters meeting and listen to the feedback you get. You may not be able to practice the whole speech, but you can do 5 to 7 minute segments of your speech. As an added bonus, you will be getting really useful feedback about your general speaking habits. You can find a Toastmasters club near you at http://www.toastmasters.org/ . »

If you have further suggestions or tips, please do not hesitate to reply to this post or email me.

CSP Formation
Partenaire de DantotsuPM

Hello, thanks to the numerous feedbacks that readers of this post sent me, I prepared this follow up message to summarize their wise advices for the benefits of all.

Applicability:

·Big or little conference, ‘small’ internal presentation or not – most guidelines apply everywhere.

·Any ‘public talk’ is an opportunity to get comfortable with the techniques. That way you’ll be ready when that large conference arrives!

Preparation:

·A difference between usual presentations and big events/conferences is the time between when you know you have to talk and the date of the speech, and the associated deadlines

·Another difference for large events is the distance with the audience – both physically and mentally and the supporting material that you have to provide. Take the time to find out what the audience cares about and be flexible enough to change. It’s never about you, it’s always the audience, if they do not hear what you are saying it’s your problem not theirs. Check to make sure you are on the same wavelength.

·Anticipate and plan your communications with the people that you need to agree with (the external communications department of your company for instance).

·Always be clear on cost & impact, i.e. what is at stake? Do not inflict unnecessary stress on yourself.

In practice:

·I always start with « my name is ………………… and I love my job ». If you are not passionate about what you do, why should the audience?

·I have a slide that says here are the three things I would like you to walk away with. Refer back to the three things in your closure.

·I would add that no matter what, if you make a mistake or if you have a blank (and it does happen even to the most prepared speaker) take a deep breath.  To the speaker, it will seem forever, to the audience, it will just give them time to mull over what you said before. This gives the speaker a rest to get his/her bearings back.  Light humor always helps also.

·Test the projections on a very large screen. Images that look acceptable on a computer screen or a smaller projector can look pixelated when projected to a convention wall.

·If you have an assistant, make sure that you have worked out the signal to move slides BOTH forward and backward.

·Make sure you utilize the restroom BEFORE they attac

Hello, thanks to the numerous feedbacks that readers of this post sent me, I prepared this follow up message to summarize their wise advices for the benefits of all.

Applicability:

  • ·Big or little conference, ‘small’ internal presentation or not – most guidelines apply everywhere.
  • ·Any ‘public talk’ is an opportunity to get comfortable with the techniques. That way you’ll be ready when that large conference arrives!Preparation:
  • ·A difference between usual presentations and big events/conferences is the time between when you know you have to talk and the date of the speech, and the associated deadlines
  • ·Another difference for large events is the distance with the audience – both physically and mentally and the supporting material that you have to provide. Take the time to find out what the audience cares about and be flexible enough to change. It’s never about you, it’s always the audience, if they do not hear what you are saying it’s your problem not theirs. Check to make sure you are on the same wavelength.
  • ·Anticipate and plan your communications with the people that you need to agree with (the external communications department of your company for instance).
  • ·Always be clear on cost & impact, i.e. what is at stake? Do not inflict unnecessary stress on yourself.

In practice:

  • ·I always start with « my name is ………………… and I love my job ». If you are not passionate about what you do, why should the audience?
  • ·I have a slide that says here are the three things I would like you to walk away with. Refer back to the three things in your closure.
  • ·I would add that no matter what, if you make a mistake or if you have a blank (and it does happen even to the most prepared speaker) take a deep breath.  To the speaker, it will seem forever, to the audience, it will just give them time to mull over what you said before. This gives the speaker a rest to get his/her bearings back.  Light humor always helps also.
  • ·Test the projections on a very large screen. Images that look acceptable on a computer screen or a smaller projector can look pixelated when projected to a convention wall.
  • ·If you have an assistant, make sure that you have worked out the signal to move slides BOTH forward and backward.
  • ·Make sure you utilize the restroom BEFORE they attach the microphone.
  • ·Join Toastmasters so you can practice your speech before a live audience. Try out anything that you are uncertain about at a Toastmasters meeting and listen to the feedback you get. You may not be able to practice the whole speech, but you can do 5 to 7 minute segments of your speech. As an added bonus, you will be getting really useful feedback about your general speaking habits. You can find a Toastmasters club near you at http://www.toastmasters.org/ . »

h the microphone.

·Join Toastmasters so you can practice your speech before a live audience. Try out anything that you are uncertain about at a Toastmasters meeting and listen to the feedback you get. You may not be able to practice the whole speech, but you can do 5 to 7 minute segments of your speech. As an added bonus, you will be getting really useful feedback about your general speaking habits. You can find a Toastmasters club near you at http://www.toastmasters.org/ . »

Qui d’autre veut se préparer au mieux pour présenter lors d’une grande manifestation ? (la suite)

Merci ! Grâce à vos nombreux commentaires sur l’article  » une bonne préparation permet de réaliser de meilleures présentations dans les conférences « , j’ai compilé cette suite au message initial pour partager avec tous vos conseils avisés.

Applicabilité :

  • Grande ou petite conférence, « petite présentation interne » ou pas – la plupart des conseils du premier article s’applique partout.
  • Toute « conversation publique » est une opportunité d’être plus à l’aise avec ces techniques. De cette manière vous serez prêts quand le grand jour arrivera!

salle de conférencePréparation :

  • Une différence entre les présentations habituelles et les événements marquants ou grandes conférences est le temps entre le moment où vous savez que vous devez parler et la date du discours ainsi que les limites imposées.
  • Une autre différence pour de grands événements est la distance avec l’auditoire – tant physiquement que mentalement ainsi que le matériel de support que vous devrez fournir. Prenez le temps de découvrir ce qui intéresse l’auditoire et soyez assez flexible pour changer. Ce n’est jamais à propos de vous, c’est toujours à propos de l’auditoire, s’ils n’entendent pas ce que vous dites que c’est votre problème pas le leur. Vérifiez  pour vous assurer que vous êtes sur la même longueur d’ondes.
  • Prévoyez de revoir vos communications avec les personnes avec lesquelles vous devez être d’accord (le département communications externes de votre société par exemple).
  • Soyez toujours clair sur le coût et l’impact, c’est-à-dire quel est l’en jeu ? Ne vous infligez pas de stress inutile.

En pratique, quelques trucs :

  • Je commence toujours par « mon nom est ………………… et j’aime mon travail ». Si vous n’êtes pas passionnés de ce que vous faites, pourquoi l’auditoire devrait-il l’être ?
  • J’ai une diapositive qui dit « voici les trois choses avec lesquelles je voudrais que vous vous repartiez ». Référez-vous à ces trois choses dans votre conclusion.
  • J’ajouterais que si vous faites une erreur ou si vous avez un trou (et cela arrive même au speaker le mieux préparé), respirez à fond. Pour le speaker, cela semblera durer une éternité, pour l’assistance, cela leur donnera tout juste le temps de réfléchir à ce que vous avez dit précédemment. Cela donne à l’orateur un espace pour se retrouver. Un léger trait d’humour aide également.
  • Vérifiez la projection de votre matériel sur très grand écran. Les images qui semblent acceptables sur un écran d’ordinateur ou un projecteur plus petit peuvent apparaître « pixelisées » quand elles sont projetées sur un grand écran de convention.
  • Si vous avez un assistant, assurez-vous que vous avez mis au point le signal pour déplacer les diapositives TANT en avant qu’en arrière.
  • Assurez-vous que vous utilisez les toilettes AVANT qu’ils n’attachent le microphone.
  • Rejoignez le réseau Toastmasters où vous pourrez pratiquer votre discours devant un auditoire bien vivant. Essayez quoi que ce soit dont vous êtes incertains lors d’une réunion Toastmasters et écoutez les réactions. Vous pouvez ne pas être en mesure d’y pratiquer votre discours en entier, mais vous pouvez y réaliser 5 à 7 parties de votre discours. En bonus supplémentaire, vous obtiendrez des retours vraiment utiles sur votre attitude générale. Vous pouvez trouver un club de Toastmasters près de chez vous sur http://www.toastmasters.org/

Si vous avez de nouvelles suggestions ou trucs, n’hésitez pas à commenter cet article ou à me les envoyer par courrier électronique.

CSP Formation
Partenaire de DantotsuPM

20 erreurs courantes faites par les chefs de projet nouveaux ou inexpérimentés Par Harold Kerzner, Ph. D., PMP

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

Twenty Common Mistakes Made by New or Inexperienced Project Managers By Harold Kerzner, Ph.D., PMP

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

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

ERREUR #1 : trop de détail

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

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

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

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

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

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

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

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

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

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

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

ignorer des problèmes ignoring problemsERREUR #5 : Ignorer les Problèmes

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

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

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

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

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

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

plaquer à l'or fin - gold plating deliverablesERREUR #7 : Placage à l’or fin des Livrables

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

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

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

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

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

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

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

ERREUR #10 : Refus de Demander de l’Aide

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

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

ERREUR #11 : Ignorer un Problème

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

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

ERREUR #12 : Croire aux Sauveurs et aux Miracles

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

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

mentirERREUR #13 : Promettre des Récompenses

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

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

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

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

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

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

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

ERREUR #16 : Montrer à tous qui est le Patron

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

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

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

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

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

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

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

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

ERREUR #19 : Ne pas Dire « Non »

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

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

ERREUR #20 : Ne pas Choisir les bonnes batailles

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

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

CSP Formation
Partenaire de DantotsuPM

5 choses tangibles à faire pour de jeunes PMs souhaitant accroître leurs capacités

Mel Bost – PMO Expert a remarqué dans son article « Five Tangible Things Aspiring Young Project Managers Can Do to Enhance Their Capabilities » que de nombreux jeunes chefs de projet interrogent leurs ainés plus expérimentés et leaders de PMO sur comment améliorer leurs compétences en management de projet.

Il leur conseille les 5 choses suivantes :

se porter volontaire1. Se porter volontaire pour prendre les minutes d’une réunion importante d’avancement de projet. Assurez-vous de trouver ou créer un modèle qui capture les participants, la date et la durée de la réunion, l’ordre du jour, les actions ont été agréées, les tâches assignées à chaque participant et leurs dates de fin, les problèmes  non résolus et la date et heure de la prochaine réunion. En vous portant volontaire pour cette mission, vous fournirez un document clef à l’équipe de projet sur lequel ils peuvent se baser dans tout le projet.

2. A la conclusion et documentation du contenu du projet, questionnez le sponsor et les parties prenantes pour vous assurer qu’ils connaissent vraiment sur quels contenus ils signent et « l’engagement » nécessaire pour réaliser le projet. Ceci vous donnera une visibilité des “Changements de Portée” qui peuvent surgir avant des demandes de changement effectives. Cela augmentera votre compréhension du processus de projet et votre stature parmi les autres chefs de projet.

3. A la fin de la première phase majeure du projet, insistez pour que l’équipe de projet tienne une session sur “les leçons apprises”. Ils vous remercieront plus tard même si vous devez les traîner à la réunion à leur corps défendant.
taking notes, prendre des notes

4. Identifiez un problème qui semble diviser les membres de l’équipe de projet ou les parties prenantes et suive-le en enregistrant des actions majeures et les décisions prises par l’équipe et les parties prenantes. À un moment approprié dans le projet, quand il apparaît que l’équipe projet ou les parties prenantes ou les deux se sont trouvent dans une impasse ou un point délicat, sortez votre résumé des actions et des décisions et passez-les en revue avec ce groupe combiné. Certains peuvent ne pas apprécier d’être confronté avec les faits, d’autres peuvent ne pas être d’accord avec vos « faits » ou votre interprétation – mais personne ne pourra nier l’harmonie qui en résultera quand chacun commencera à voir les perspectives et points de vue différents des autres ni ne critiquera le fait qu’un observateur « raisonnable et réaliste » a porté ces points de vue à leur attention.

5. Pratiquez les quatre mécanismes de communications dont j’ai discuté dans un de mes articles précédents.


CSP Formation
Partenaire de DantotsuPM

créer et délivrer des présentations efficaces

Voici quelques conseils additionnels pour bien préparer vos prochaines interventions qui complète l’un de mes billets précédents: une bonne préparation permet de réaliser de meilleures présentations dans les conférences

Si vous êtes dans l’audience plutôt que sur scène, n’oubliez pas de lire: comment tirer le maximum des événements professionnels auxquels vous participez

L’article original librement traduit ici est « Creating and delivering effective presentations » de Gina Abudi

présentation en publicQue vous deviez donner des présentations occasionnellement ou régulièrement, il est important de vous préparer efficacement en avance pour la présentation pour vous assurer que vous atteindrez vos buts. Rappelez-vous que les présentations sont essentielles au business. Elles informent et instruisent votre auditoire et leur permettent de vous connaître ainsi que votre société par leur biais. Vous pouvez utiliser une présentation pour convaincre un client d’utiliser votre produit ou service plutôt que ceux d’un concurrent. Plus votre présentation est concise et ciblée, plus vous êtes dynamique dans la présentation de l’information à votre auditoire, plus probablement le résultat sera réussi.

Il y a quelques choses auxquelles vous devriez penser  avant que vous ne développiez votre présentation, dont :

  • Quel est l’auditoire ?
  • Quel est le but de la présentation ?
  • Comment devez-vous communiquer l’information ?
  • Comment réaliserez-vous un suivi avec l’auditoire après la présentation ?

Regardons chacune d’entre elles dans plus de détail.

Quel est l’auditoire?

salle de conférenceQuelle connaissance votre auditoire possède-t-il du sujet que vous présentez ? En connaissent-ils déjà une bonne partie et ont-ils besoin d’information spécifique, ou cherchent-ils une vue d’ensemble ou une introduction du sujet ? Vous attendez-vous à ce qu’ils soient satisfaits de l’information que vous délivrez – est-ce le message qu’ils veulent entendre ? Ou…plutôt, le message est-il négatif pour eux ? Combien de personnes suivront la présentation ? Y-a-t-il possibilité de réaliser une session interactive avec beaucoup de questions et réponses, ou bien – présentez-vous à un très grand groupe pour transmettre de l’information et non pas rechercher de l’interactivité ?

Plus vous connaissez de votre auditoire et leurs attentes; mieux vous pouvez préparer la présentation pour vous assurer qu’elle est efficace et fournit à l’auditoire ce qu’ils veulent et ont besoin de votre part.

Quel est le but de la présentation ?

objectif but Pensez à ce que vous essayez de réaliser avec cette présentation. Est-ce qu’une décision est attendue à la fin de la présentation pour enclencher quelque chose ? Est-ce que la présentation va seulement donner matière à réflexion ? Est-ce une session de suivi fournissant le statut d’un projet ? Essayez-vous de vendre à d’autres votre idée et de faire approuver un budget ? Le but de la présentation guidera ce que vous développerez.

Par exemple, si la présentation est concentrée sur l’obtention de l’approbation d’un budget pour avancer avec un projet, vous voudrez inclure des études de cas et exemples de projets passés. Vous voudrez être sûr que votre auditoire comprend la valeur d’y aller – quel sera le résultat final et comment il leur profitera ?

Gardez votre présentation succincte et précise – présentez aussi peu de messages clefs que possible pour garantir la compréhension et avoir un impact sur votre auditoire. Vous ne voulez pas que votre présentation en donne tant qu’ils n’auront aucune idée du but de la présentation ni de ce qu’ils doivent faire.

Si vous avez des documents à distribuer et qu’ils ne sont pas nécessaires pour la présentation, mais sont plutôt à prendre en partant pour référence, fournissez-les à la fin de la présentation pour qu’ils ne les distraient pas de votre présentation.

Comment devez-vous communiquer l’information ?

Une règle de préparation et de présentation efficace est : “dire à l’auditoire ce que vous allez leur dire, le leur dire et leur rappeler enfin ce que vous venez de leur dire.” Sans doute avez-vous entendu cette règle plusieurs fois. Utilisez-la pour structurer votre présentation :

  • Introduction
  • Message
  • Résumé
  • Conclusion

Nous discuterons de ces sections ci-dessous.

Tenez compte en développant votre présentation du fait que les diapositives vont soutenir votre propos; vous ne devriez pas lire des diapositives, mais plutôt utiliser le contenu des diapositives comme un rappel de ce que vous présentez à l’auditoire.

Si votre présentation dure plus d’une heure, assurez-vous qu’il y a au moins 15 minutes de pauses sur la durée.

Regardons chacune des sections de la présentation dans un peu plus de détail.

Diapositives d’introduction

Les diapositives d’introduction devraient inclure :

  • Des introductions (quelque chose sur votre expérience, particulièrement si les personnes ne vous connaissent pas)
  • Un agenda
  • Les objectifs de la présentation (“dites à votre auditoire ce que vous allez leur dire”)

Le point principal des diapositives d’introduction est de présenter la présentation pour que les gens sachent à quoi s’attendre. Communiquez-leur la durée la présentation (rappelez-vous toujours laisser du temps pour les questions!). Si vous préférez que les questions soient traitées à la fin de la présentation, faites le savoir dès le départ. Demandez si l’auditoire a des questions avant d’entamer la partie principale de la présentation.

Diapositives de message (de contenu)

Les diapositives de message, ou de contenu, sont la partie principale de votre présentation. Rappelez-vous la règle ci-dessus ? Voici le moment où vous “leur dites” ce que vous avez dit que vous alliez leur dire. La majorité de vos diapositives se trouvera dans cette section. Vous pouvez découper cette section en de multiples sections plus petites si nécessaire, particulièrement pour des présentations longues. Si vous découpez votre présentation en sections plus petites, assurez-vous que chaque section a sa propre page d’introduction (et agenda pour cette section) et une diapositive de résumé qui boucle la section.

Quelques meilleures pratiques pour vos diapositives incluent :

  • L’utilisation de visuels comme des images, des dessins et des diagrammes pour transmettre plus facilement l’information
  • Si les diagrammes sont compliqués – retenez seulement l’information de base sur la diapositive et fournissez aux participants des documents avec une information plus détaillée
  • Mettez un texte minimal sur les diapositives – le contenu devrait être des sujets de conversation pour le présentateur – pas des lignes et les lignes de texte qu’il est difficile de lire – utilisez des listes à puces
  • N’utilisez pas trop de sous-points car cela réduira la lisibilité
  • Utiliser des diapositives de transition entre chaque section de votre présentation
  • Utilisez une diapositive de résumé pour conclure votre présentation
  • Assurez-vous que le texte est lisible – Qu’il se détache sur le fond de diapositive et qu’il est facilement lisible du fond de la pièce
  • N’utilisez pas trop de couleurs dans votre modèle de diapositive – faites simple et professionnel
  • Gardez les titres de diapositive à une taille de caractère de 30 à 32 points
  • Le texte de la liste à puces devrait être à 24–26 points pour assurer une bonne lisibilité

Diapositives de résumé

Vos diapositives de résumé récapituleront les points principaux de votre présentation. “Rappelez à votre auditoire ce que vous venez de leur dire.” Une session de questions et réponses fera partie de votre résumé. Demandez à l’auditoire s’ils ont des questions sur votre présentation. Répondez aux questions clairement et précisément. Si vous ne connaissez pas la réponse, c’est acceptable – admettez que vous n’êtes pas sûrs de la réponse et dites à la personne qui l’a posez que vous reviendrez vers elle quand vous l’aurez. Et rappelez-vous de donner suite!

Diapositives de conclusion

Votre dernière diapositive devrait être votre diapositive finale. Remerciez les personnes pour leur participation et incluez un « prochaines étapes ». Pendant la clôture de votre présentation, récapitulez les points clefs abordés dans la session questions/réponses, noter les suivis nécessaires et distribuer les documentations pertinentes. Demandez à votre auditoire de vous contacter (assurez-vous que vos coordonnées soient sur la diapositive!) s’ils ont des questions ou voudraient approfondir le sujet.

Comment réaliserez-vous un suivi avec les personnes après la présentation ?

suiviVotre présentation exige-t-elle un suivi ? Par exemple, si vous présentiez à un nouveau client vos capacités dans l’espoir de gagner un business, cela exigera un suivi. Dans une telle situation, faites un suivi avec votre client le lendemain de la présentation – les remercient pour leur temps et demandent s’ils ont des questions ou exigent plus d’information. Donnez suite selon vos procédures de gestion. Si votre présentation était sur un projet et a exigé une décision, dans votre conclusion de la présentation, demander à l’auditoire quand une décision sera prise et assurez-vous de donner suite à ce moment-là. Votre suivi  variera selon la situation et le but de la présentation. Si la présentation a pour objectif de partager de  l’information et des connaissances avec l’auditoire(par exemple, en présentant à une conférence), vous pourriez simplement demander que l’auditoire vous contacte directement pour toutes questions ou nouvelles informations.

La prochaine fois vous avez une présentation – pensez à qui vous présentez à et quel est  le but de la présentation. Planifiez ce que vous allez dire – créez un plan pour vous assurer que vous couvrez tous vos points dans le temps alloué. Meilleure la préparation, plus probablement vous obtiendrez un résultat réussi.

Vos idées ? Que faites-vous pour vous préparer pour des présentations ? Qu’avez-vous trouvé utile ?

CSP Formation
Partenaire de DantotsuPM

La courtoisie favorise la collaboration

Un article très original de Ty Kiisel intitulé « Common Courtesy Conducive to Collaboration ».

Il peut paraître trivial voire un peu rétrograde de reconnaître la courtoisie la plus élémentaire comme élément prépondérant dans l’établissement de bonnes relations de travail, et pourtant, combien de fois est-elle piétinée dans le monde du travail ?

« Common Courtesy Conducive to Collaboration »

Je me suis souvent demandé, pendant les presque trente dernières années de ma carrière, pourquoi il semble que la confrontation brutale semble souvent l’emporter sur la courtoisie dans les organisations. J’ai tendance à être d’accord avec Emerson quand il a écrit, « Il y a toujours une meilleure façon de faire toute chose, même si c’est seulement faire bouillir un œuf. Les bonnes manières sont les façons heureuses de faire ces choses. »

Dans des organisations où la collaboration efficace est critique au succès du projet, la qualité de nos interactions avec nos pairs, nos supérieurs et nos subalternes est importante — Voici pourquoi je crois qu’une communication cordiale est si importante pour le succès du management de projet.

En mai 1940, Neville Chamberlain a été démis de son poste de Premier ministre de la Grande-Bretagne pour son échec de répondre à la menace de guerre de l’Allemagne. En tant que Premier ministre nouvellement nommé, sa première intervention devant le Parlement est celle où Winston Churchill a dit le fameux, « je n’ai rien à offrir que du sang, un dur labeur, des larmes et de la sueur. »

Cependant, mon point pour mentionner Winston Churchill n’est pas de discuter sa capacité à rassembler l’Angleterre pour repousser une invasion allemande potentielle, mais de reconnaître sa bienveillance et générosité d’esprit envers un ancien rival au passage. Je crois qu’il aurait été facile de frapper et de châtier le Chambellan pour son inaction, cependant Churchill s’est rendu compte que le faire ne servirait en rien pour promouvoir la cause de la liberté et ternirait seulement le nom de l’ancien Premier ministre et abaisserait le sien.

Au lieu de cela, voici un petit extrait de ce que Churchill a dû dire aux obsèques du Chambellan, « C’est tombé sur Neville Chamberlain lors de l’une des crises suprêmes du monde d’être contredit par les événements, d’être déçu dans ses espoirs et trompé et déçu par un mauvais homme. Mais qu’étaient ces espoirs pour lesquels il a été déçu ?… Ils étaient sûrement parmi les instincts les plus nobles et bienveillants du cœur humain — l’amour de la paix… Quoi que l’histoire puisse dire ou pas de ceux des années épouvantables, incroyables, nous pouvons être sûrs que Neville Chamberlain a agi avec une parfaite sincérité selon les lumières et est allé à l’extrême de sa capacité et autorité … de sauver le monde de la lutte terrible, dévastatrice dans laquelle nous sommes maintenant engagés. »

Nous travaillons dans un âge de messagerie instantanée, d’email et autres communications presque instantanées. Nous ne devrions pas laisser l’immédiateté du média nous autoriser à devenir durs et trop « faciles » dans notre manière d’approcher nos collaborateurs, même quand les problèmes surgissent et que des erreurs sont commises. Même sur le lieu de travail actuel, il y a une place pour la courtoisie.

  1. Prenez du temps pour rendre votre communication réfléchie et cordiale : Quand les délais sont raccourcis et demandent aux équipes projet d’en faire de plus en plus, prenez quelques secondes supplémentaires pour écrire un email ou autre communiqué afin de considérer que votre communication est destinée à une personne. J’aime commencer chaque email par une salutation, qui me rappelle que j’écris à quelqu’un. Les deux ou trois secondes supplémentaires que cela me demande pour m’adresser directement à la personne n’impactent pas négativement ma productivité, mais cela m’aide vraiment à favoriser une relation de travail productive et cordiale.
  2. Prenez le temps d’être poli : Dans le monde imparfait du travail en mode projet, des décisions difficiles sont parfois prises — mais cela ne signifie pas que nous devons jeter la politesse par la fenêtre. Dans mes plus de trente années de carrière professionnelle j’ai observé que ce qui avait l’habitude d’être considéré comme de la courtoisie de base entre supérieurs, subalternes et collègues devient « pittoresque » et considérée « inutile ». Il n’y a rien de mal à prendre en considération les sentiments de quelqu’un qui a besoin d’être réprimandé, aussi stupide que vous pensiez qu’ils soient ou combien était grande l’erreur qu’ils aient fait. Étant poli et prévenant l’un envers l’autre est le moins que nous devrions être capables d’attendre de nos collègues « professionnels ». En faire à moins est improductif et immature.
  3. éliminez la critique de la critique « constructive » : on m’a appris très tôt dans ma carrière, par des amis et des collègues beaucoup plus avisés que moi, que la « critique » n’était jamais « constructive ». Je ne pense pas avoir travaillé dans une seule équipe de projet qui soit tout le temps d’accord. Le management de projet implique beaucoup de créativité dans la résolution de problèmes, ce qui signifie que l’on réussi rarement du premier coup. La stimulation d’un environnement créatif où les membres d’équipe résolvent avec créativité des problèmes et insistent sur l’excellence exige la collaboration, pas la critique. Quand les désaccords surgissent ou un changement de direction est exigé, « je n’aime pas cela, » devrait être suivi par, « voici pourquoi et voici une suggestion sur comment vous pourriez procéder. »

La communication efficace ne repose pas sur des tours de magie ou des trucs. À mon avis, il est important de se souvenir que la communication efficace est personnelle. Il importe peu si c’est en face à face, via l’email, ou même dans un blog, c’est une personne qui interagit avec une autre. Les outils de gestion de projet peuvent aider à faciliter la communication et la collaboration, mais le type de communication dépend seulement de vous.

L’auteur américain et le dramaturge Jean Kerr ont dit, « l’Homme est le seul animal qui apprend en étant hypocrite. Il feint d’être poli et ensuite, finalement, il devient poli. »

Que faites-vous dans votre organisation pour encourager l’interaction prévenante et courtoise entre collègues ?