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

Le 29 octobre 2010 par mopertodans experience sharing, forum de discussionLaisser un commentaire

Une fois n’est pas coutume, je ne suis pas 100% en ligne avec les propositions de Ty, traduites ci-dessous.

En particulier sur sa neuvième recommandation qui suggère de toujours répondre par « oui » aux demandes des parties prenantes en indiquant simplement le coût associé à ce « oui ».

Par exemple : « Oui, nous pouvons réaliser cette nouvelle fonctionnalité en augmentant le budget de 10% et en décalant d’un mois la date de livraison. »

Mon expérience personnelle est que trop souvent la contrepartie ou les conditions nécessaires pour autoriser ce « oui » seront occultées par une grande majorité des parties prenantes qui n’entendront que le « oui » de début de phrase. Or, les conditions qui permettraient ce « oui » n’existent pas au moment où il est prononcé : besoin de budget additionnel, report au niveau des délais, ajouts de personnels et de compétences, compromis sur le contenu des livrables ou la qualité…

Je suggérerais donc, dans cette situation, de choisir d’adopter la position de dire « non » suivi d’un « sauf à » faire ceci ou cela (à augmenter les ressources, à réduire les exigences, à reporter la date de livraison…).

Par exemple : « Cet augmentation de fonctionnalité semble en effet attractive, mais nous ne pouvons pas y répondre…

… sauf à augmenter le budget de 10% et décaler la date de livraison d’un mois ».

Ceci permet à mon avis d’être beaucoup plus clair sur l’incidence de passer outre à ce « non ».

Voici la traduction de l’article de Ty Kiisel:

Presenting to Project Stakeholders: 10 Tips to Effective Communication

Maintenir une ligne de communication ouverte et efficace avec les parties prenantes est important. Il y a deux ou trois ans je suis tombé sur cette liste d’astuces pour mieux présenter aux parties prenantes, qui méritent d’être revues. Parfois il semble que l’efficacité d’une réunion de trente minutes puisse être conclue dans les dans soixante premières secondes. Les parties prenantes ont parfois des laps de temps d’attention très courts. Si vous ne captez pas leur attention dans les deux premières minutes, ils commenceront à vérifier leur courrier électronique et regarder l’horloge ou pire, quitteront votre réunion.

Toute personne impliquée dans un projet doit traiter avec des sponsors et des parties prenantes. Ayant cela en mémoire, voici dix astuces qui pourraient aider vos interactions :

1. Piquez leur curiosité : un ordre du jour est toujours une bonne idée, mais un bref résumé de ce qui sera discuté est encore mieux. En plus, on donne aux parties prenantes quelque chose à prendre dans la rencontre et cela leur permet de venir préparée avec des questions.

2. Ne supposez pas qu’ils connaissent le travail attendu de leur part en tant que partie prenante : Ils pourraient en avoir une vue de haut niveau, mais vous devrez probablement expliciter les détails.

3. Faites simple : Exposez-leur la situation en termes directs. Ne les noyez pas d’informations. Restez-en à l’essentiel. (Cependant, soyez prêt à entrer dans les détails s’ils commencent à poser des questions.)

4. Utilisez des chiffres et des images : PowerPoint est un excellent outil pour présenter des graphiques et des chiffres aux parties prenantes. C’est la façon dont elles se présentent les informations entre elles. Vous devriez en faire autant.

5. Parfois vous devez utiliser la logique : Acceptez le fait qu’il pourrait ne pas toujours y avoir des données pour supporter une situation particulière. Ne pas avoir de chiffres pour soutenir votre position pourrait rendre un bon argument problématique, dans ce cas vous devriez vous tourner vers une logique « si … alors … » pour expliquer une situation. Cependant, ne vous attendez pas aux mêmes résultats ou à la même réponse de la part des parties prenantes car avec elles les chiffres font loi.

6. Temporiser n’est jamais une bonne option : n’attendez pas qu’un problème soit évident — il est souvent plus difficile de résoudre le problème à ce moment-là.

7. Offrez toujours une solution : si vous venez exposer un problème sans offrir une solution potentielle, vous pourriez aussi bien demander les parties prenantes : « Virez-moi tout de suite. » Trouver des solutions fait partie de votre travail de chef de projet.

8. Spécifiez les actions qu’ils doivent entreprendre : si les parties prenantes doivent agir, ne supposez pas que ce sera évident pour elles. Récapitulez — sous forme de liste — quelles actions doivent être prises et quand.

9. Dites toujours » oui », mais assurez-vous qu’ils comprennent combien coûtera ce « oui« : les Sponsors et des parties prenantes n’aiment pas entendre « Non », donc ne le dites pas. Assurez-vous simplement qu’ils comprennent le coût de leur requête, alors ils peuvent juger par eux-mêmes si « oui » vaut vraiment le coup.

10. N’arrêtez pas de reporter sur le statut du projet parce que les parties prenantes arrêtent de l’exiger : la perception est la réalité. Si les parties prenantes perçoivent que vous ne faites rien : c’est que vous ne faites rien. Ne laissez pas votre tête être la suivante sur le billot.

Indépendamment de la méthodologie de management du travail de votre société, il y a beaucoup d’outils de management de projets disponibles pour faciliter la gestion des tâches et des délais qui vous aideront à communiquer plus efficacement avec les parties prenantes dans votre organisation. Que votre outil de management de projet facilite ou pas cette forme de communication, ignorer cette partie importante de votre rôle de chef de projet est dangereux. Que faites-vous dans votre organisation pour encourager une relation positive avec les parties prenantes ?

CSP Formation — Partenaire de DantotsuPM

Leadership, do you have what it takes? Do not miss the October 2010 edition of PM Network !

Le 28 octobre 2010 par mopertodans forum de discussion, leadershipLaisser un commentaire

Hello,

please check out the article related to leadership in PM Network October 2010 edition.

I’ve been interviewed and I contributed to this article together with many other PMs (starting page 74 onwards)

I’m famous ! 🙂

Cheers, Michel.

nouvelles certifications de APM Group en management de Projet Agile et Earned Value Management

Le 28 octobre 2010 par mopertodans agile, formations et certifications1 commentaire

APM Group, qui propose déjà les certifications Prince 2 élargit son offre avec deux nouvelles certifications: Management de projet Agile et Earned Vamue Management (EVM).

Deux niveaux de qualification Agile Project Management sont prévues: « Foundation » et « Practitioner ». Seule la certification « Foundation » est pour l’heure disponible.

La certification EVM, est elle aussi pour le moment seulement disponible en version « Foundation » avec un test à choix multiples de 40 questions sur une heure couvrant votre compréhension de la terminologie et connaissance théoriques des méthodes de Management par la Valeur Acquise.

Si vous décidez de passer ces certifications, merci de nous donner vos retours d’expérience.

PMGS Formations en management de projet — Partenaire de DantotsuPM

comment être certifié Programme Management Professional (PgMP) par le Project Management Institute (PMI)

Le 27 octobre 2010 par mopertodans formations et certifications1 commentaire

La certification PgMP® reconnaît votre expérience, connaissance et performance à manager de nombreux projets inter-connectés et alignés sur un but stratégique et un objectif organisationnel. Elle atteste, non seulement vos compétences en management de projet, mais aussi de votre capacité à délivrer des résultats et des bénéfices pour le business qui nécessitent :

Une Vision Stratégique de l’entreprise permettant d’avoir un Portefeuille de projets cohérents.
Une Gouvernance d’Organisation matérialisée par un Planning Stratégique, qui permette la transition effective entre le Management par Projets et la Gestion Opérationnelle de l’entreprise

Au premier semestre 2010, il y a eu plus de 400 PgMP® certifiés dans le monde. La certification PgMP® s’adresse à des responsables qui :

gèrent des programmes qui contiennent des activités complexes, notamment des activités transverses touchant plusieurs fonctions, organisations, régions géographiques et cultures.
suivent, informent et maintiennent la communication avec l’ensemble des parties prenantes aux différents niveaux de l’entreprise.
possèdent des compétences avancées en finance, leadership, management des différences culturelles, communication, négociation et résolution de conflits

Comment devenir PgMP® ?

Critères d’admission

Expérience en management de projet :
- Avec un niveau inférieur à Bac + 4, vous devez justifier au cours des quinze dernières années d’un minimum de 6000 heures d’expérience en management de projet et 10500 heures en management de programme.
- Avec un niveau Bac+4, le candidat doit justifier au cours des quinze dernières années d’un minimum de 6000 heures d’expérience en management de projet et 6000 heures en management de programme.

Les étapes

1 – Formulaire d’application en ligne sur le site du PMI® : www.pmi.org

Ce formulaire très détaillé exige que vous vous remémoriez et documentiez votre expérience de Chef de Projet et de direction de programme. Il faut y être précis et factuel, lister les projets, votre rôle exact sur ceux-ci, les dates de début et de fin, les organisations/sociétés et les contacts dans chacune de celles-ci ainsi que vos liens avec ces contacts…
Truc utile : s’assurer que vos expériences de management de projet et de programme sont bien distinctes tant sur les périodes que les projets.
En sus de cette description d’expérience, il vous faudra fournir des résumés d’expérience dans 8 domaines du management de projet et de programme.
Après l’approbation de votre dossier, votre candidature sera examinée par une commission du PMI composée d’expert en management de programme.

2 – l’Examen

Suite au passage réussi de cet examen par la commission, le PMI vous envoie une lettre d’éligibilité qui vous permet de prévoir la date de votre examen PgMP® dans les 12 mois suivants.
Vous planifiez la date de votre examen auprès d’un centre Prometrics et passez l’examen informatisé.
Ou bien l’examen papier si votre chapitre PMI local en organise (c’est le cas dans le sud de la France) www.pmi-fr.org .
L’examen dure 4 heures et comporte 170 questions à choix multiples en anglais
Le système de notation est différent de celui de PMP car les questions ont une pondération qui dépend de leur degré de difficulté. Mais leur coefficient ne vous est pas indiqué pendant l’examen, donc efforcez-vous comme toujours de bien répondre à toutes les questions.

3 – 360°

Suite à la réussite de l’examen, vous devrez passer une « évaluation 360° ». Cette évaluation à 360° est réalisée sur Internet par 12 de vos collègues qui devront évaluer votre candidature à travers 74 questions: Un superviseur, quatre pairs, quatre personnes en rapport direct avec le candidat et trois références professionnelles de votre choix.
La réussite de cette dernière évaluation permet enfin l’obtention du titre PgMP®.

Conserver sa certification

Pour maintenir votre certification PgMP® il vous faudra acquérir 60 Professional Development Units (PDUs) au cours de chaque cycle de trois ans.

Pour plus de détails, lisez le PgMP Handbook.

5 choses que les Organisateurs d’Événements recherchent de la part de leurs intervenants

Le 25 octobre 2010 par mopertodans best practices, forum de discussionLaisser un commentaire

Traduction d’un article d’une lettre d’information Slideshare que je vous invite par ailleurs à découvrir.

Autres articles sur ce thème:

Les organisateurs d’événements attendent des intervenants qu’ils ou elles :

1) Comprennent quelle est la communauté pour laquelle l’événement est destiné – parvenez à connaître votre auditoire avant l’événement. Passez un certain temps avec eux (en ligne ou en personne) et assurez-vous que vous êtes bien en ligne avec les sujets les plus appropriés de discussion ou le débat. Cela aidera aussi si vous voulez avoir une session de questions/réponses. Découvrez qui sont les autres intervenants et faites leur appel. Cela vous aidera à construire un momentum et de la camaraderie bien avant l’événement, lui-même.

2) Fassent la promotion de l’événement – les suiveurs, contacts et lecteurs réguliers d’un speaker sont une bonne source de participants potentiels à une conférence. Les organisateurs sont conscients de cela et remarqueront quand vous promouvez activement l’événement auprès de votre communauté. Mettez un billet sur votre blog, dans les calendriers partagés, sur des sites web et réseaux sociaux.

3) Soient fiables – les organisateurs choisiront les speakers qui se présentent à l’heure, ont tous leurs matériels, sont préparés pour toute éventualité impromptue et peuvent s’adapter aux changements de dernière minute. Vos réputation à de l’importance. Beaucoup d’intervenants ne s’en rendent pas compte, mais les organisateurs de conférence de différents d’événements comparent leurs notes et discutent entre eux pour partager leurs expériences de travail avec les speakers, sur et en dehors de la prestation sur scène.

4) S’attendent à de l’inattendu – quand on en vient aux événements professionnels, la Loi de Murphy prévaut. Ne supposez pas qu’il y aura une connexion Internet fiable. Si vous avez le projet de présenter une démonstration « en direct”, assurez-vous de préparer des copies d’écran en secours au cas où la connexion Internet ne serait pas aussi rapide ou stable que nécessaire.

5) Participent à l’événement – n’arrivent pas juste au dernier moment par avion, parlent puis s’envolent à nouveau. Peu importe combien vous êtes occupé, l’événement est votre client et l’auditoire est une extension de votre communauté. Soyez accessible et dégagez du temps pour vous entretenir avec des participants dans les halls, lors d’autres sessions, au déjeuner. Soyez enclin à faire un podcast impromptu et soyez prêts à avoir votre photo prise avec des participants. Cela vaudra bien votre temps, vous rencontrerez des personnes intéressantes et, en plus, vous pourriez bien apprendre quelque chose!

gagner des PDUs est chose facile

Le 22 octobre 2010 par mopertodans formations et certifications2 commentaires

Earning PDUs is a Breeze Écrit par John Reiling

Beaucoup de Professionnels de Management de projet (PMPs) trouvent que c’est un défi pour eux de gagner leurs 60 Unités de Développement Professionnel (PDUs) exigées tous les 3 ans. Ce n’est pas nécessairement aussi difficile ni intimidant que certains le pensent!

C’est en réalité tout à fait facile et cela peut (et devrait) s’insérer dans une routine et s’accorder avec les buts ordinaires tant professionnels de la plupart des professionnels. Voici quelques idées de comment les PMPs peuvent facilement gagner les 60 PDUs requis dans le cours naturel de leurs activités.

Avoir des objectifs Personnels et Professionnels est la Clé

D’abord, pensez aux buts d’un Chef de projet ou d’un Directeur de programme qui doit gagner ces PDUs. Il ou elle a beaucoup de responsabilités qui exigent des compétences diverses, souvent apparentées aux compétences d’un Directeur Général. En fait, beaucoup de PMs aspirent à devenir un jour des Directeurs Généraux. Aussi, vraiment, la première étape vers l’incorporation des PDUs dans le cours normal de l’activité est de déterminer des objectifs personnels et professionnels!

Préparer un Plan d’exécution

Avec ces buts en mémoire, la question suivante est « Comment réaliserai-je ces objectifs, disons, à un horizon de 3 ans ? » Vraisemblablement, ces buts demandent de construire des compétences, de travailler sur certains types de projets, d’acquérir de l’expérience avec certains types de problèmes et certaines situations, de construire un réseau professionnel et d’affûter avec la plus grande importance ses compétences relationnelles. Étant donné qu’un Chef de projet doit être un communicateur fort et un leader, un penseur stratégique ayant la vue d’ensemble et un constructeur d’équipe qui inspire, une excellente approche est de concevoir un programme personnel et de le réaliser en gagnant des PDUs en même temps.

Il s’agit de planification

D’abord, il est bon de ne pas laisser ce type de réflexion stratégique et de mise en place d’objectifs personnels pour la dernière minute. C’est en réalité du management de projet de base ! Les buts professionnels sont par nature à moyen ou long terme, donc un peu de planification est nécessaire. …

Il s’agit d’exécution

Donc, quels sont les exigences du PMI et comment les PMPs peuvent-ils s’en servir pour réaliser leurs objectifs personnels et professionnels ? D’abord, la source autorisée pour la re-certification PMP est le Manuel de PMI appelé « Continuing Certification Requirements (CCR) Handbook ». Il décrit les cinq catégories dans lesquelles les PMPs peuvent gagner des PDUs, elles sont passées en revue ci-dessous dans l’esprit de leur acquisition facile dans le cours normal du travail.

Catégorie 1

Enseignement Universitaire Formel. Cela se réfère à l’enseignement et à la formation dans des universités accréditées. Les cours sur le management de projet et/ou de programme sont qualifiants, ils doivent se rapporter aux processus de management de projet et secteurs de connaissance du PMBOK. Les PMPs doivent parler avec l’université et PMI pour clarifier le nombre pour PDUs que chaque cours apportera.

Catégorie 2

Activités Professionnelles et Étude Auto-dirigée. Cette catégorie se positionne gentiment dans le temps et les objectifs de beaucoup de PMPs, mais il y a quelques limitations sur combien de PDUS peut être revendiqués dans certains cas. Voici quelques exemples :

a. Écrire un livre – jusqu’à 40 PDUs

b. Le travail de management de projet quotidien (c’est-à-dire le travail de n’importe quel PMP, s’il inclut 1,500 heures par an en tant que chef de projet) – 5 PDUs par an.
c. Enseigner un cours de gestion de projet – jusqu’à 10 PDUs
d. Être orateur à une manifestation de chapitre PMI local – 5 PDUs.
e. Étudier de manière autonome (c’est-à-dire lire un livre de management de projet, écouter un podcast orienté management de projet) – jusqu’à 15 PDUs par cycle de 3 années et exige d’en apporter ‘la preuve’

Catégorie 3

« Registered Education Providers (REPs) » Fournisseurs d’Enseignement Reconnus par le PMI (liste). Cela inclut les cours en salle de classe relativement chers, ou des cours en ligne moins chers de formation en management de projet (1 PDU par heure de cours selon les règles de PMI). D’autres options, avec le réseautage en avantage supplémentaire, incluent les dîners ou réunions mensuels des chapitres de PMI (1-2 PDUs) ou des séminaires spéciaux et des réunions des Groupes d’Intérêt Spécifiques de PMI (« Specific Interest Groups – SIGs »).

Catégorie 4

Autres Fournisseurs de formation. La formation liée au management de projet par des organismes non certifiés par PMI est aussi qualifiante, un fait qui est généralement mal compris des PMPs. Cela inclut des séminaires, des cours internes en management de projet et en ligne d’organismes non-certifiés dont le contenu correspond aux Processus de PM et secteurs de Connaissance de PMI. Comme la formation par des REPs, la formation par des non-REPs qualifie pour 1 PDU par heure de cours selon les règles de PMI. LE PMI exige des descriptions de cours et des justificatifs ou des transcriptions en cas d’audit.

Catégorie 5

Service de Volontaire. Le volontariat peut être pour un Chapitre PMI ou une autre organisation de volontaires où le management de projet est clairement exercé. Les élus au bureau du chapitre gagnent 10 PDUs et les volontaires réguliers 5 PDUs par an. Les PDUs gagnés peuvent facilement correspondre à bien moins que les heures passées, mais d’autres avantages incluent la croissance de son réseau de pairs, l’engagement dans la communauté des PMs et le développement personnel qui vient avec le volontariat.

Un Appel à l’Action pour les PMPs

Le but des PDUS est de garder les PMPs engagés et de grandir professionnellement. Le simple appel à l’action est pour des Professionnels de management de projet d’évaluer leurs besoins de PDUs et de les relier à leurs objectifs personnels et professionnels. Il suffit alors de trouver ses méthodes favorites, comme décrites ci-dessus et selon le PMI’s « PMP Credential Handbook », puis entrer dans l’action sur une base régulière vers la réalisation de ses objectifs – et de gain de PDUs.

Paul Naybour referenced DantotsuPM in his Directory of the Best Project Management Sites

Le 21 octobre 2010 par mopertodans pointeurs utiles1 commentaire

Thank you Paul !

By the way, the « posts » section of Paul’s web site holds some great articles such as:

Le multitâche vous ralentit

Le 21 octobre 201021 octobre 2010 par mopertodans agile, forum de discussion5 commentaires

Multitasking Gets You There Later article de Roger Brown

Le business moderne repose sur le multitâche pour réaliser le travail. Les salariés sont évalués sur leur capacité à travailler en parallèle sur de multiples tâches. Les professionnels de l’informatique sont habituellement assignés à de multiples projets. Avons-nous toujours fait cela ? Le multitâche marche-t-il ? Quels sont les impacts réels du multitâche ? Il y a une alternative ?

Monotâche serait le nom pour représenter comment nous avons eu l’habitude de travailler sur le logiciel avant le multitâche. Par multitâche, je veux vraiment dire « le travail en parallèle sur de multiples projets ». Le business moderne en est venu à appeler cela « multitâche » et à le considérer comme une stratégie pour une production plus efficace des employés. Nous faisons aussi du multitâche à une petite échelle dans nos vies quotidiennes, au travail et en dehors. Il y a des ressemblances à la fois sur comment nous le faisons et sur ce qu’il nous fait.

Une Perspective Différente

Quand nous présentons l’approche Agile (ou Scrum) à de nouvelles personnes, une des plus grandes pierres d’achoppement est l’idée que les équipes travaillent beaucoup beaucoup mieux quand leurs membres sont dédiés à l’équipe à plein temps. Ce n’est pas nouveau. Pendant des années nous avons assemblé « des équipes tigre (tiger team) » et « équipes de choc (swat teams) » pour traiter des problèmes spéciaux, souvent en temps de crise. Cependant, nos organisations en sont venues à préférer un modèle basé sur des individus organisés par silos de compétence assignés à de multiples projets en même temps. C’est devenu la solution de facto pour avoir un grand nombre de choses réalisées en même temps. On le considère comme étant l’utilisation la plus efficace « des ressources rares », c’est-à-dire pas suffisamment de personnes et toutes spécialisées.

Le modèle Agile retourne ce modèle sur sa tête. Formons des équipes de personnes concentrées sur un petit ensemble de choses à la fois. Au lieu de créer le travail et de faire passer les personnes au travers, nous créons les équipes de personnes et faisons passer le travail vers elles. Et nous tirons au lieu de pousser.

Le changement est difficile. Faire les choses de manière différente demande un objectif clair, une vision des bénéfices et du courage. Donc la résistance est naturelle; les personnes ne se sentent pas en sécurité quand les choses commencent à changer autour d’elles. Si nous pouvons faire un changement vers le mode « LEAN », nous pouvons démultiplier deux principes centraux « du respect pour les personnes » et « améliorer continuellement le système » pour définir un objectif, prévoir les bénéfices et entamer les premières étapes vers l’amélioration. Beaucoup de personnes entendent « LEAN » et pensent comment mieux faire ce que nous faisons déjà. « LEAN » dit aussi que nous pouvons souvent éliminer encore plus de gaspillage si nous arrêtons complètement de faire certaines choses, des activités de faible valeur.

Les coûts du Multitâche

Une personne qui travaille sur plus d’un projet encourt un coût à chaque passage d’un projet à l’autre. Le coût primaire est le temps requis pour changer de contexte. Nous savons que des interruptions simples comme un appel téléphonique peuvent coûter au moins 15 minutes de temps de récupération. Plus la tâche est complexe, plus il faut de temps pour effectuer le changement.

Si vous travaillez sur plus de deux projets à la fois le coût peut être encore plus élevé. Il peut s’être écoulé beaucoup de temps depuis que vous avez travaillé pour la dernière fois sur ce projet, demandant plus d’efforts pour vous souvenir d’où vous vous êtes arrêtés. Alternativement, si vous changez fréquemment, votre temps de commutation de contexte demandera une plus grande proportion de votre temps de travail.

Il y a des études qui montrent que les personnes sont assez douées pour des changements entre deux contextes sur de petites tâches. Sur une période de temps réduite, cela semble avoir un rapport avec nos deux hémisphères cérébraux. Jusqu’à un certain degré, nous pouvons travailler en parallèle sur deux tâches indépendantes. Pour de plus grands changements, nous devrions nous attendre à un certain coût de commutation. Jerry Weinberg a montré que le contexte s’intensifiant, si chaque tâche a une pénalité de 10 %, en réalité les coûts cumulés sont fréquemment plus hauts.

Quand une personne fait partie d’une équipe, traditionnelle ou Agile, il y a un coût additionnel de commutation. Quand un membre de l’équipe part pour faire une tâche non liée au travail de l’équipe, l’équipe souffre de l’absence du membre. Quand le membre absent revient, l’équipe passe du temps à l’aider à rattraper les événements qui se sont produits pendant son absence.

Multitâche Agile ?

Mais, vous pouvez dire: « attendez un peu ». Une équipe Agile est transversale et occupée à faire toutes sortes d’activités chaque jour. Celles-ci incluent l’élaboration de besoins, l’analyse, le design, les tests et la programmation. N’est-ce pas du multitâche ? La réponse dépend de la portée de contexte. De vastes sauts de sujet et de technologie exigent plus de temps de commutation. Le cerveau est excellent avec les faibles changements d’activités. Sur une équipe resserrée, toutes les activités quotidiennes sont centrées sur une bande réduite de fonctions et technologies. Seulement quelques « storyboard » sont travaillés en même temps. Le contexte est étroit bien que l’éventail d’activités soit varié. De plus, Agile a un certain nombre de dispositifs pour garder le focus – la collaboration, les tableaux de tâche, le test automatisé, l’examen rétrospectif. Ce sont les larges sauts de contexte qui créent problèmes – d’autres projets, d’autres collaborateurs, d’autres parties prenantes.

Neuroscience de Multitâche

Le cerveau humain est fort en multitâche interne. Il le fait tout le temps. Il le fait même la nuit. Il y a beaucoup de parties du cerveau qui fonctionnent ensemble et seules tout le temps. Sinon, nous ne pourrions pas fonctionner dans nos environnements complexes. La plupart du multitâche est subconscient – le filtrage d’apport sensoriel, l’intégration d’informations connectées, déplacer des données de la mémoire à court terme vers celle à long terme, maintenir le cœur et les poumons en marche.

Et nous faisons du multitâche extérieurement – conduire de la voiture tandis que nous naviguons et écoutons les informations de circulation, parler au téléphone pendant que nous dînons, planifier des vacances en sarclant le jardin. Quelques tâches comme plier le linge, marcher, etc. sont mécaniques et n’encourent pas de coût de commutation de tâche. D’autres comme de naviguer à travers un document en frappant des touches ou renommer une méthode peut être faites mécaniquement après quelque temps. Mais le travail de développement logiciel n’est pas si simple. Beaucoup de ce travail en multitâche automatique marche bien. Cependant, il a vraiment des limites.

La commutation de contexte de missions multi-projet modernes crée une nécessité potentielle de re-travail mental. L’intelligence humaine a deux sortes de mémoire séparées – à court terme (la mémoire de travail) et le long terme. Il y a des mécanismes pour déplacer des informations entre les deux. Il n’y a aucune garantie que tout est déplacé ou que les informations entrant sont les mêmes qui en reviendront plus tard. Nous éditons constamment nos mémoires, à chaque fois nous les rejouons. De nouvelles informations doivent résider dans la mémoire à court terme pendant un certain temps avant d’être déplacées dans la mémoire à long terme. Par exemple, le bachotage peut vous permettre d’obtenir une meilleure note mais vous risquez de vous rappeler peu de choses deux semaines plus tard. Simplement, il est possible que vous ne puissiez pas conserver les dernières choses sur lesquelles vous avez travaillé avant la commutation de contexte. Et celles-ci sont probablement les choses que vous voulez le plus vous rappeler quand vous revenez sur le projet.

La recherche suggère beaucoup de façons dont le multitâche est inefficace ou même nuisible.

Considérez :

Il y a évidence que le multitâche dégrade en réalité la mémoire à court terme, pas seulement sur les sujets du multitâche, mais probablement en ayant un impact sur certains secteurs du cerveau. Le multitâche crée du stress; le stress invoque les parties plus primitives du cerveau qui sont concernées par la sécurité personnelle, tirant l’énergie des parties plus modernes centrées sur la pensée de plus haut niveau. Le stress peut aussi endommager des cellules nécessaires pour de nouvelles mémorisations.
Nous sommes plus enclins aux erreurs quand nous faisons du multitâche aussi la qualité de nos résultats de travail baisse. Cela, bien sûr, ajoute des coûts au projet parce que les choses devront être réparées.
Quelques parties du cerveau sont des processeurs séquentiels, capables d’accepter seulement une saisie à la fois.
Le cortex préfrontal, la partie du cerveau la plus utilisée pour la connaissance complexe et la prise de décisions, est la plus grande consommatrice d’énergie dans le cerveau. La charge supplémentaire du multitâche mènera à un épuisement plus rapide de capacité cognitive et un besoin plus fréquent de temps de récupération.

Monotâche pour Équipes Agiles

Comment réduire la quantité de multitâche pour des personnes dans un contexte Agile ? Nous y avons mentionné quelques approches. Un environnement plus physique engage davantage de parties du cerveau, menant à la synthèse plus rapide et plus complète d’informations. Un effort plus concentré maintient une portée de contexte étroite. Des interactions humaines et un ScrumMaster pour faciliter certaines des interactions aideront à garder ce focus.

Quelques pratiques techniques modernes améliorent le focus, par exemple :

Le Développement piloté par les tests permet de focaliser le travail technique dans un court laps de temps.
L’intégration continue aide à porter une attention immédiate à un « build » raté ou test non réussi.
« Pair programming » permet à deux personnes de se concentrer sur un petit secteur de code.

Monotâche pour Organisations

On connaît les arguments contre le multitâche depuis longtemps, cependant notre culture d’entreprise moderne est habituée à cette forme « d’équilibrage de charge » pour maximiser l’utilisation efficace de « ressources » humaines. Nous assemblons les équipes de personnes dans de libres groupements de fournisseurs de compétences travaillant à temps partiel sur plusieurs choses à la fois. Pouvez-vous construire une équipe à hautes performances à partir de membres à temps partiel ? comment en sommes-nous venus à penser qu’il est plus important que chacun semble être occupé tout le temps ?

Une des parties les plus difficiles d’apprendre est de devoir désapprendre les comportements actuels. C’est vrai pour les organisations autant que pour les individus, il est simplement difficile de faire le saut mental depuis ce que nous faisons maintenant à ce qui pourrait mieux fonctionner. Voici un argument visuel simple qui pourrait aider à guider un changement qui est non seulement plus facile sur les personnes, il a du sens financièrement.

Un scénario simple montré dans la Figure suivante comporte 4 personnes travaillant sur 3 projets courts. La dynamique est la même pour davantage de personnes et de plus grands projets. Dans le premier scénario, les gens font du multitâche sur 4 projets

La figure: Personnes en Multitâche

La figure qui suit montre un deuxième scénario dans lequel les mêmes personnes forment une seule équipe et complète les projets séquentiellement. Ce scénario fait la supposition très conservatrice qu’il n’y a aucun gain de productivité de teaming ou du nombre réduit de commutations de contexte. Remarquez que tous les projets sont achevés à la même date dans les deux scénarios, mais que 2 des 3 projets finissent plus tôt dans ce scénario. Imaginez les bénéfices financiers résultants.

La figure: Formez une Équipe pour Faire les Projets Séquentiellement

Avec la réduction de commutation de contexte et un modeste gain de 10 % dans la productivité en raison des synergies teaming, nous nous attendrions même à voir tous les projets finir plus tôt comme illustré dans la Figure suivante.

La figure : Une réalisation plus courte grâce au monotâche et aux synergies d’équipe

Johanna Rothman couvre ce sujet plus en détail dans : « Gérez Votre Portefeuille de Projet »

La Variété est l’Épice de la Vie

Si le multitâche est clairement mauvais, nous devrions ne jamais le faire, n’est-ce pas ? Alors comment le concilions-nous avec l’idée que « la variété est l’épice de vie » ? Des recherches sur le cerveau ont montré que la nouveauté est attractive – elle produit la dopamine, un neurotransmetteur qui nous fait en redemander. La réponse a un rapport avec le focus et la portée. Si la commutation de contexte est importante, le multitâche prend un droit de passage sur la personne et ses collaborateurs. Si la commutation est faible, elle convient à notre manière de penser et peut très bien marcher. Nous obtenons une dose de nouveauté suffisante dans un contexte d’équipe Agile en apprenant l’un de l’autre et en produisant d’autres bons neurotransmetteurs par nos achèvements et nos succès.

Conclusion

La commutation de contexte entre les projets prend du temps et est un coût pour l’organisation. Plus il y a de projets impliqués et plus ils sont complexes, plus le coût est élevé. En se concentrant sur une chose à la fois pendant une période plus longue, les individus peuvent travailler plus efficacement. En formant des équipes pour aborder des projets séquentiellement, nous pouvons réduire le coût de commutation de contexte et gagner encore davantage par des synergies d’équipe.

Sélectionner les bons projets exige la bonne approche

Le 20 octobre 201027 novembre 2010 par mopertodans Non classé2 commentaires

Selecting the Right Projects Requires the Right Approach

Jack S. Duggal, MBA, PMP sur PMI.ORG

Le management de portefeuille de projet (PPM) concerne la sélection des bons projets, mais souvent cette sélection n’est pas basée sur une approche appropriée.

PPM s’est développé ces dernières années avec une multitude de modèles, des critères et de mécanismes de score pour la sélection et la priorisation. Quand vous adaptez le management de portefeuille à votre organisation, les objectifs et les critères de classement peuvent facilement se multiplier et devenir trop détaillés et complexes, perdant l’essence même du management de portefeuille.

L’approche que vous adaptez peut ne pas être appropriée pour votre organisation ou trop compliquée. En résulte que PPM n’est pas bien compris et n’obtient pas l’adhésion et l’engagement de toutes les parties prenantes.

Pour augmenter la pertinence et l’efficacité du processus, il est important revoir et d’ajuster votre approche en tant que partie du processus de revue de portefeuille. The Standard for Portfolio Management—Second Edition décrit le processus complet de management de portefeuille.

Voici les questions à considérer comme vous passez en revue votre l’approche d’élaboration de scores PPM:

1) Notre approche se concentre-t-elle sur les bons critères ?

L’essence du management de portefeuille est de vous aider à prendre les bonnes décisions d’investissement basées sur l’évaluation du risque par rapport au bénéfice. Le management de portefeuille de projet ajoute la disponibilité des ressources et leurs capacités ainsi que l’alignement stratégique dans l’équation. L’analyse de risque, du bénéfice et des ressources n’est pas en elle-même significative si les projets ne sont pas alignés sur la stratégie et les objectifs fonctionnels.

Ces cinq facteurs se combinent pour former la Base pour des critères de sélection réfléchis de PPM.

Bénéfice : une combinaison de retours tangibles (par exemple, retour sur investissement, la « net present value ») et des avantages plus intangibles (par exemple, la satisfaction client).
Risque : Tels que la probabilité de succès, les risques liés à l’exécution ou la livraison, etc.
Ressources : les personnes, les ressources financières et matérielles.
Alignement Stratégique : nouveaux marchés, sécurité, croissance, innovation, etc.
Alignement avec les objectifs fonctionnels : Par exemple, augmentation du revenu, réduction de coûts d’évitement de coûts.

2) Avons-nous les bonnes pondérations pour chaque critère ?

Tous les critères ne sont pas d’égale importance et vous pouvez avoir assigné des poids différents, mais sont-ils appropriés et valables ? Les pondérations décidées initialement pourraient devoir être recalibrées avec des changements d’objectifs ou de conditions d’affaires.

3) Avons-nous le bon mélange de critères ? Est-il équilibré selon différentes perspectives?

Souvent il y a trop d’accent sur le bénéfice financier quantitatif et pas assez d’importance donnée aux critères qualitatifs comme la satisfaction client, la réputation, la morale, le prestige, l’efficacité, etc. Le but devrait être d’avoir un bon mélange de critères avec un équilibre entre :

Quantitatif et qualitatif;
Tangible (dur) et intangible (doux);
Direct et indirect;
Perspectives à court terme et à long terme.

4) Nous concentrons-nous sur la bonne comparaison de projets et leur inter-relation et l’impact de choisir un projet par rapport à un autre ?

Il est courant de noter les projets et les classer dans un format de tableur. Mais ceci fournit seulement une analyse individuelle de projet, ce qui n’est pas suffisant. L’étape suivante est de visualiser ces projets sur un graphe et montrer comment ils se comparent les uns par rapport aux autres. C’est typiquement illustré en utilisant des graphiques à plusieurs variables avec des bulles comparant deux facteurs ou plus. Par exemple, le graphique ci-contre dépeint le coût par rapport au bénéfice. La taille de la bulle correspond aux besoins en ressources et la couleur de la bulle représente la classification de projet.

5) Avons-nous la bonne Classification de projet?

Pour faire de bonnes comparaison et priorisation de projets, ils doivent être classifiés dans des catégories appropriées. Vous pouvez les classifier dans des catégories génériques comme “faire tourner l’activité”, “développer le business” ou “transformer l’activité,” ou bien de plus spécifiques pour les systèmes d’information comme infrastructure, transactionnel, producteur d’informations ou bien stratégiques. La clé est de s’assurer que la classification est appropriée à votre activité et qu’elle aide à mettre en évidence les caractéristiques importantes et la distribution du portefeuille.

6) Avons-nous la bonne gouvernance de PPM, avec les bonnes personnes engagées au bon niveau ?

Vous devriez développer une bonne approche de gouvernance en collaboration avec le département de management du portefeuille, le PMO ou le comité responsable du portefeuille. Autrement, vous pouvez vous attendre à une adoption limitée, au sapement du processus ou de jeux sur les scores de certains en faveur de leurs projets préférés.

Souvenez-vous, il n’y a pas d’unique meilleure approche. Il est important de peaufiner l’approche de PPM et de l’ajuster afin de trouver la bonne.

Pour plus sur le management de portefeuille, voir les articles sur ce theme de M. Duggal Cultivating a Portfolio Mindset (Community Post, 14 November 2008); To Focus on the Right Projects, Categorize and Classify (Community Post, 12 December 2008); How to Prioritize and Balance Tough Portfolio Decisions (Community Post, 8 May 2009).

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

Le 19 octobre 2010 par mopertodans experience sharing, forum de discussion5 commentaires

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

Les jalons qui sont significatifs aux sponsors business peuvent être définis au moment, ou peu après, la création de la charte de projet. Ceux-ci peuvent ensuite être modifiés pendant la planification initiale et le développement de concept de la solution, avec la participation du sponsor et des parties prenantes. Ces jalons, créés et modifiés avec l’engagement du client, sont alors insérés dans un planning détaillé de projet, avec les événements marquants de progrès du projet comme le début d’une phase.

En travaillant sur la création de jalons significatifs, on devrait être attentif à s’assurer que « le langage de solution technique » ne s’introduise pas subrepticement dans les jalons. Cela fait peu de bien que de parler avec un sponsor peu intéressé par la technologie d’un concept technique comme la création d’un modèle de données informatiques. Bien que ce soit un événement marquant significatif dans la création d’un produit informatique, il a peu de pertinence pour un manager qui essaye de réduire le temps de rotation de son processus ou réduire ses dépenses! Il est certainement utile d’inclure des événements marquants techniques pour suivre de près le progrès de la perspective de l’équipe technique, mais utiliser seulement ces éléments comme jalons de projet pour les parties prenantes business est une invitation à cheminer par un très long « tunnel ». La création de jalons et leur suivi sont des choses à ne pas prendre à la légère!

Découpez le Projet en phases de 9 mois ou moins

La manière la plus fondamentale, et cependant souvent la plus difficile d’éviter le « tunnel sombre et tortueux » est d’éviter la tentation de créer un long projet d’une unique phase. Un principe fondamental des méthodologies « agiles », des projets plus petits ou de plus grands projets découpés en plusieurs phases de livraison sont très efficaces pour maintenir l’intérêt des parties prenantes de l’organisation dans le projet. Les parties prenantes sont plus engagées simplement parce qu’elles perçoivent les bénéfices du projet plus tôt et plus souvent.

Tandis que cette approche est relativement évidente pour certains projets, d’autres, comme la mise en œuvre d’un gros ERP, peuvent être plus difficiles. Ces projets plus compliqués et vastes devraient être planifiés par phases, avec des fonctionnalités délivrées à intervalles réguliers. Pas plus que neuf mois devraient se passer entre l’expression des exigences et la livraison de la fonctionnalité! La planification d’un projet être difficile de cette façon, mais cela peut être fait et les bénéfices à le faire le valent bien. Ces bénéfices incluent :

Éviter les problèmes de changements de priorité business ou de manque « de continuité d’attention » de l’entreprise. Les projets seront plus probablement complétés quand la valeur business est délivrée à intervalles réguliers.

Introduire le changement dans la communauté des clients avec une ampleur et une allure qu’ils puissent absorber. Les projets longs qui produisent de gros livrables présentent une somme considérable de changements d’un seul coup. Ce seul fait peut créer des problèmes d’assimilation du changement pour les utilisateurs finaux, peut renforcer des problèmes de processus business et générer un mécontentement. Gardez les changements petits, livrez-les régulièrement et vous ferez plus probablement des clients heureux.

Garder la fraîcheur des exigences business. Des projets plus longs ont souvent des problèmes avec un périmètre et des besoins changeants tout simplement parce que le business que le projet supporte ne reste pas statique. C’est un monde business qui bouge rapidement et montre peu ou pas de signes de ralentissement. Des projets plus longs délivrent simplement sur des exigences éventées ou dépassées. Maintenir un cycle (ou des phases) court de l’expression des besoins à la livraison et vous aurez moins de problèmes d’obsolescence et de volatilité des exigences.

Managez et Comprenez la Longueur « du trajet »

Les triples contraintes de projet sont établies tôt dans le projet. Bien sûr, elles devraient changer comme on découvre de plus en plus le détail du projet et la solution exigée. Malgré cela, certains des paramètres généraux pour le projet sont établis très tôt. Une période satisfaisante pour la livraison – la considération sur l’ampleur du changement et la complexité du projet, est décidée tôt en tant que partie des triples contraintes. Cependant, ceci est souvent oublié quand les demandes de changement sont traitées, les ajustements de priorité causés par des changements business et d’autres événements inattendus sont rencontrés par l’équipe de projet. Nous avons une tendance à nous concentrer sur le micro niveau de changement et à oublier la macro période du projet – ce que nous avons à l’origine utilisé pour justifier le lancement du projet! Manager le niveau macro période du projet exige la chose suivante :

Pendant les premières étapes de planification du projet, mettez une durée désirable pour le projet et « une durée au risque acceptable ». La durée au risque acceptable est une durée qui est plus longue que celle prévue à l’origine, cependant elle est toujours acceptable pour les clients business et l’équipe de projet. Cette durée de risque devrait considérer le degré de volatilité business, le paysage compétitif de votre secteur d’application et la capacité à conserver les membres d’équipe avec les bonnes compétences sur la durée projetée.

Se focaliser sur l’impact à long terme d’accepter des changements au projet. Un processus de management des changements standard devrait être exigé sur tout projet. À un certain point cependant, idéalement quand on s’approche « de la durée de risque acceptable », la portée entière du projet devrait être réévaluée. Tous les changements qui ne sont pas achevés devraient être reconsidérés et priorisés. Le périmètre – au macro niveau – peut alors être évalué pour assurer que le projet reste dans une période acceptable.

Le tunnel « sombre et tortueux » est un endroit solitaire pour un chef de projet. La planification diligente, le management attentif des changements et un œil sur la vue d’ensemble, en plus des procédures de management de changement typiques peuvent maintenir votre projet en vie et vos clients heureux. Et ce n’est pas mal pour votre santé mentale personnelle non plus!

: Partenaire de DantotsuPM

Où sont les participants ?

Le 18 octobre 2010 par mopertodans experience sharing, forum de discussion, leadershipLaisser un commentaire

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

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.

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

Le 15 octobre 201018 octobre 2010 par mopertodans experience sharing, forum de discussionLaisser un commentaire

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

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

2. Détails. Vous ne pouvez pas en avoir trop

Les besoins décrits sur une seule ligne de mots (« one liners ») n’aident pas à concevoir et développer un système. Mais c’est souvent ce que vous obtenez. Et chacun l’interprétera en fonction de leur propre connaissance et expérience. Vous ne pouvez pas acheter d’assurance contre une mauvaise interprétation. Vous devez obtenir une bonne vue d’ensemble, mais vous devez aussi entrer dans les détails infimes. Demandez des détails, même quand la question semble mineure. Vous pouvez y découvrir quelque chose de vraiment critique.

3. Comprendre le business, pas les besoins exprimés

Ne regardez pas de besoin en isolation. Les besoins existent pour supporter une exigence business. Parvenez à connaître ce qu’est ce business- tout aspect de celui que vous essayez de supporter. Une fois que vous avez cela, les liens entre les diverses pièces du puzzle commencent à apparaître. Les besoins tombent simplement à leur place. Vous savez ce qui est critique et pourquoi. La bonne solution apparaît quand vous retournez à la planche à dessin.

4. Tout documenter

Pendant que vous rassemblez les besoins, vous obtenez une quantité énorme de données, souvent sous formes disparates. Des textes, des feuilles de tableur, des présentations PowerPoint, des graphiques et images. La liste est infinie. Documentez, indexez et conservez chaque morceau d’informations que vous rencontrez par hasard et utilisez un bon outil logiciel. Demandez à chacun dans le projet de tout documenter dans une base de données centralisée, pas sur leurs bureaux. Gardez-les à jour. Il n’y a aucun doute que le contexte et la compréhension qui vient avec un document ne peut pas toujours être traduit en besoins. Mais, quand une personne quitte le projet ou l’organisation, vous ne pouvez pas vous permettre de perdre quoi que soit des informations qui existent dans ses cellules grises. Documentez. Quelqu’un regardant les besoins n’aura pas besoin de réinventer plus tard ce que l’on connaît déjà.

5. Impliquer les utilisateurs. Les utilisateurs réels

Les utilisateurs réels sont ceux qui savent le mieux, mais souvent ce sont leurs patrons qui viennent aux réunions avec les analystes (« busines analysts ») et l’équipe de développement. Les hommes en costumes sombres ont probablement la vue d’ensemble et peuvent probablement définir les besoins plus clairement, mais les utilisateurs réels du système sont ceux qui connaissent les éléments clefs et les points de douleur. Impliquez-les chaque fois que vous le pouvez. Particulièrement quand la rentabilité et les flux de travail qui sont clefs au succès du système.

6. Aller les voir travailler

Souvent ce que disent les utilisateurs n’est pas ce qu’ils veulent dire en réalité. Les raisons sont multiples. Ce pourrait être à cause d’un écart de communication, parce qu’ils supposent que de certaines choses sont juste trop basiques pour être mentionnées, ou simplement oubliées. Observez-les dans l’action. Ne vous contentez pas de regarder, observez! Vous serez agréablement surpris des résultats. Le flux de processus est souvent le facteur le plus critique au succès du système en construction. Malheureusement la plupart des collectes de besoins se passe entre les quatre murs d’une salle de conférence ou sur des conférences téléphoniques, pas sur place. Voyez les choses dans l’action, pas dans votre imagination. Souvent, j’ai constaté qu’une heure passée sur place valait plus qu’un jour entier de discussion.

7. Chercher le « chemin malheureux »

Trop souvent nous finissons par construire un système qui traite parfaitement bien le flux normal. Chacun peut vous dire ce qu’est le « chemin heureux »; mais seuls ceux qui utilisent le système dans un contexte business réel peuvent vous dire tout ce qui peut mal tourner. Et si vous ne construisez pas votre système pour traiter les choses qui « peuvent aller mal », vous avez construit un château de cartes. Ne demandez pas simplement aux utilisateurs le « chemin heureux » », encouragez les à vous parler du « chemin malheureux ». Mais souvenez-vous; demandez aux vrais utilisateurs.

8. Aller dans les coulisses

Avec des systèmes multiples mis en œuvre dans l’environnement de travail de nos jours, souvent les utilisateurs ne savent plus quel le système fait quoi. C’est totalement transparent pour eux. La transparence est bonne du point de vue des utilisateurs, mais pas pour ceux qui cherchent à construire un nouveau système. Les utilisateurs vous diront ce qu’ils pensent que fait leur système existant. Efforcez-vous de connaître la portée du système que vous essayez de construire ou remplacer. Impliquez les gens techniques qui peuvent fournir ces informations pour éviter de devoir refaire.

9. Trouver les documentations

Cherchez le manuel système et guide utilisateur. Vous en trouverez beaucoup prenant la poussière dans un coin oublié. Alors que les utilisateurs peuvent vous parler de choses qu’ils font souvent, il y a des choses dont ils ne se rappellent pas – ou ne comprennent pas. Un document correctement approuvé peut être une mine d’or d’informations. Il pourrait vous dire non seulement ce que le système fait, mais aussi pourquoi. Le pourquoi peut être décisif quand vous devez prendre certaines décisions sur inclure ou pas une fonctionnalité spécifique dans le nouveau système.

10. Construire un nouveau système, ne pas copier l’ancien

Souvent les utilisateurs veulent que le nouveau système fasse les choses exactement de la même façon que le système précédent. Les personnes au sommet seraient aussi heureuses puisque cela diminuerait le coût de formation et éviterait des erreurs. La plate-forme technologique que vous utilisez pour le nouveau système pourrait être bien meilleure, mais faire les choses d’une manière peu familière aux utilisateurs. Obtenez l’engagement de la direction. Faites que les utilisateurs sachent qu’il va être différent. Après tout, vous construisez un nouveau système, vous ne produisez pas une copie de l’ancien !

11. Construire des besoins ou des limitations ?

Il n’est pas rare que des utilisateurs demandent quelques fonctionnalités dans le nouveau système basées sur ce que fait leur ancien système. Ils peuvent sincèrement croire que c’est le besoin business alors que c’est en réalité une limitation du système existant. Personne ne se rend compte que c’est une limitation parce que c’est ce qu’ils ont toujours fait. Ne finissez pas par intégrer ces limitations.

12. Voir les rapports et les gens qui les utilisent

Vous pensez que les rapports sont la partie plus facile ? Repensez-y. Ce sont les rapports qui fournissent une vue de ce qui se passe dans l’organisation aux gens qui prennent toutes les décisions critiques. Faites une gaffe sur les rapports et vous avez fait tout ce qu’il faut pour la perte de l’organisation. À propos, l’organisation peut avoir un stock énorme de rapports qui sont produits dans le système existant, mais quelqu’un les utilise-t-il ? La construction d’un nouveau rapport coûte de l’argent. Pas seulement l’effort premier de les construire et les tester, mais ensuite le coût pour l’impression, la diffusion, le stockage et la destruction. Et oui, vous augmentez aussi votre empreinte carbone. La diminution du nombre de rapports de moitié quand un nouveau système est introduit n’est pas rare du tout. Regardez-le comme une opportunité de nettoyer l’inventaire de rapports.

La bonne équipe avec le bon niveau de temps investi peut être la clé du succès de la phase la plus critique de construction d’un nouveau système. Prenez votre temps, tout à fait littéralement. Cela peut faire la différence entre un projet réussi et un échec.

d’où viennent les bonnes idées ?

Le 14 octobre 2010 par mopertodans forum de discussion1 commentaire

Les gens pensent souvent que leurs idées viennent dans des moments de pur génie: le fameux instant « Eureka ».

Mais Steven Johnson démontre dans ces vidéos que ses observations racontent une toute autre histoire.

En prenant des exemples concrets, de Darwin à l’invention du GPS, d’un besoin de communication entre experts à l’invention du web, le speaker décortique quelques uns des mécanismes du processus d’innovation. Voici deux variations sur ce sujet, l’une détaillée (18 minutes) et l’autre plus plus brève et ludique (4 minutes):

Utilisez des « burn down charts » dans vos rapports de management de projet

Le 13 octobre 2010 par mopertodans agile, best practices, outils et méthodesLaisser un commentaire

Use burn down Charts in your project management reports

Les Gantt Charts sont très efficaces pour comprendre le progrès et statut du projet. Mais ils sont lourds côté planification. Ils donnent peu de compréhension de ce qui se passe. Un « burn down chart » est d’autre part bon pour comprendre le progrès du projet et où en sont les livrables.

Un « burn down chart » est la représentation graphique du travail qui reste à faire par rapport au temps. Le travail en attente (ou backlog) est souvent présenté sur l’axe vertical, avec le temps en horizontal. C’est-à-dire c’est un graphe d’exécution du travail en attente (du reste à faire). C’est utile pour prévoir quand tout le travail sera terminé.

Fabrication d’un « burn down chart » sous Excel

Étape 1 : Arrangez les données pour faire un « burn down chart »

Pour faire un « burn down chart », vous devez avoir 2 jeux de données. Le calendrier des tâches réellement exécutées et celui des tâches planifiées. Comme avec la plupart des graphiques, nous devons arranger les données. Je montre 3 colonnes supplémentaires que j’ai calculées pour réaliser le graphique « burn down chart ». Vous pouvez facilement deviner les formules.

Étape 2 : Faites un bon vieux graphique à lignes

Choisissez juste les séries « Balance Planned » et « Balance Actual » et créez un graphique à lignes. Utilisez la première colonne (des jours) dans la susdite table pour les labels sur l’axe des abscisses.

Étape 3 : Ajoutez les valeurs complétées quotidiennes (Daily Completed) pour compléter le « burn down chart »

Choisissez la colonne « Daily Completed » et ajoutez-la au graphique. Une fois ajoutée, changez le type de graphique pour cette série à histogramme (lisez comment combiner 2 types de graphiques en un : combine 2 different chart types in one)

Étape 4 : Ajustez le formatage et des couleurs

Ajouter ou supprimer les lignes de grille selon vos désirs. Ajustez des couleurs et la légende si nécessaire.

Téléchargez le modèle “burn down chart”

Click here [.zip version here] to download the excel burn down chart template. Use it in your latest project status report and tell me what your team thinks about it.

Download 24 Project Management Templates for Excel

: Partenaire de DantotsuPM

faciliter le suivi d’un projet Agile avec Sharepoint

Le 12 octobre 2010 par mopertodans agile, outils et méthodesLaisser un commentaire

Dans son billet « Agile moving forward », Ryan Endres explique comment il a mis en place un environnement collaboratif basé sur microsoft sharepoint pour documenter et suivre son projet.

Ce Sharepoint projet lui permet bien sûr de stocker tous les documents projet à commencer par la charte, plan de communication, plan de test… et également les notes de réunion en permettant de plus du micro-blogging pour de échanges rapides.

Il indique aussi dans cet article le modèle de document utilisé pour décrire les besoins dans le backlog projet et leur allocation dans les Sprints de développement.

Enfin, j’aime beaucoup son idée de tourner de brèves vidéos des nouvelles fonctionnalités du produit en fin de Sprint pour garder les sponsors et autres parties prenantes informés et impliqués dans le projet.

le site de microsoft projet en français — Partenaire de DantotsuPM

5 astuces pour le parrainage des Chefs de projet seniors dans votre organisation

Le 8 octobre 2010 par mopertodans formations et certificationsLaisser un commentaire

PMI nous propose sur son blog un article fort intéressant réalisé par un groupe d’experts à propos du parrainage appliqué aux chefs de projets séniors dans l’entreprise.

Five Tips for Mentoring Senior-Level Project Managers in Your Organization

Le parrainage joue un rôle critique dans la définition de l’avenir d’une organisation. Alors que le couplage typique d’un parrain et d’un parrainé implique d’habitude d’avoir un vétéran professionnel de projet comme parrain et un collègue débutant comme parrainé, il peut y avoir des cas où le professionnel expérimenté est parrainé.

Les travailleurs expérimentés qui se tournent vers le management de projet peuvent bénéficier d’avoir un parrain, comme le peuvent les chefs de projet qualifiés chargés d’un nouveau type d’initiative. Cependant, travailler avec des professionnels expérimentés peut exiger une approche différente ou une certaine finesse.

Ici, un groupe de chefs de projet et de formateurs partage cinq astuces pour le parrainage de professionnels de niveau senior.

1. Se concentrer sur le parcours professionnel

En conseillant des chefs de projet de niveau senior, écoutez leurs perspectives sur leur parcours professionnel, objectifs et buts. Il est important pour vous de comprendre par où le parrainé est passé et le type d’expérience qu’il ou elle a alors eu, puis de connecter cela avec de futurs objectifs de carrière.

Établissez des fondations profondes pour que le parrainé senior sache comment vous vous insérez dans son parcours professionnel. Le parrainé doit comprendre comment vous, dans le rôle du parrain, l’aiderez dans la réalisation de ses buts.

2. Prendre garde aux Egos

Cela peut être un défi pour le parrain de faire accepter au parrainé qu’il y a des secteurs dans lesquels il ou elle a besoin de s’améliorer ou d’apprendre.

De même, les vétérans doivent parfois désapprendre ce que l’on leur a appris. Ils ont des expériences, des styles de management et des façons de travailler bien en place. Encouragez-les à désapprendre les pratiques et habitudes improductives et ouvrir leurs esprits à de meilleures pratiques. Pour ce faire, soulignez la valeur globale de l’approche ou du nouveau comportement dans le succès du projet.

3. Discuter davantage, diriger moins

Donner des directives est habituel dans le parrainage de chefs de projet juniors. Mais avec des professionnels de haut niveau, le dialogue bidirectionnel peut être plus efficace parce que le parrainé sait ce qui a et n’a pas marché dans ses expériences précédentes. Une discussion collaborative peut mener à une nouvelle approche soutenue par les succès précédents.

4. Renforcer le positif quand nécessaire

Au niveau junior, on s’attend souvent aux confirmations écrites et orales, mais au niveau senior, ces renforcements directs ne sont pas toujours nécessaires.

Les professionnels seniors sont d’habitude davantage pilotés par l’accomplissement personnel : une lettre de recommandation, une position ou un projet réussi, par exemple. Parce que les chefs de projet juniors manquent d’expérience et de longévité dans le domaine, ils ont tendance à bénéficier davantage d’un constant renforcement positif.

5. Apprendre du parrainé

Vous pouvez profiter de la fraîcheur de perspective que tout parrainé apporte à la table. Les professionnels de niveau senior ont eu une somme significative d’expériences et vous pourriez tirer beaucoup de profit de leur perspicacité. Ils ont peaufiné leurs approches et quand vous discutez de comment l’organisation traite certains aspects du management de projet, le parrainé pourrait même répondre à certaines questions que vous vous posez.

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

Le 7 octobre 201012 octobre 2010 par mopertodans experience sharing, forum de discussionLaisser un commentaire

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

j’adore les conférences téléphoniques…

Le 6 octobre 2010 par mopertodans forum de discussion1 commentaire

Qui n’a jamais vécu cela, n’a probablement jamais travaillé sur un gros projet international…

soyez honnête sur VOS limites

Le 5 octobre 2010 par mopertodans experience sharing, forum de discussion2 commentaires

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 ?

Vous commencez à travailler pour quelqu’un de nouveau et vous voulez faire bonne impression. Peut-être commencez-vous à garder votre BlackBerry sur vous partout et à leur répondre à toute heure de la nuit et du week-end. Chaque fois qu’ils vous envoient quelque chose, vous leur répondez que vous soyez ou pas en service.

Avec le temps vous constatez que les personnes avec lesquelles vous travaillez vous ennuient. Qu’est-ce qui se passe avec eux ? Ils vous appellent ou vous envoient un SMS à toute heure du jour et de la nuit. Quand vous ne répondez pas tout de suite, ils continuent à vous envoyer message après message. Vous devenez de plus en plus irritable. Est-il insensé de vouloir simplement quelques heures pour vous ?

À qui la faute ? C’est votre faute, n’est-ce pas ? Vous désiriez tant faire une bonne première impression que vous avez oublié que la définition des attentes est une voie à double sens. Vous avez maintenant instauré la perception du fait que vous êtes disponible 24×7. Vous ne l’avez pas nécessairement demandé. Mais, dans les faits, vous l’avez démontré par votre empressement à répondre à des communications professionnelles toute la nuit et tout le week-end.

Quand vous travaillez avec quelqu’un de nouveau ou démarrez sur un nouveau projet, vous aimez évidemment faire une bonne première impression. Mais parfois vous produisez un effort Herculéen. Autrement dit, vous travaillez si durement que vous vous tuez littéralement au travail pour faire cette bonne première impression. Vous faites quelque chose que vous ne voulez pas vraiment faire sur une base régulière. Puis, vous êtes crevé. Vous pouvez devenir amers. Peut-être commencez-vous même à avoir envie de jouer les victimes ou les martyrs. C’est vraiment votre faute; vous avez pris la décision de violer vos propres limites.

Soyez honnête sur vos limites.

Si le dimanche est le jour de la famille, le dimanche est le jour de la famille. N’acceptez pas un boulot où quelqu’un vous fait asseoir et vous dit qu’ils font des tonnes d’heures supplémentaires chaque week-end.

A utiliser avec parcimonie. Si votre patron vous envoie quelque chose et c’est important et urgent et c’est rouge et ça flashe et tout cela, prêtez-y l’attention. Mais toutes les personnes qui travaillent pendant le week-end ne s’attendent pas à ce que vous fassiez de même.

Si je suis votre nouveau manager, directeur, vice-président, chef de projet, chef d’équipe, superviseur, et que je vous vois travailler de longues heures, je pourrais simplement supposer que c’est votre manière de fonctionner. Je pourrais supposer que vous vivez pour le travail. Je vais même le prendre pour acquis; je vais m’y attendre de vous tout le temps. Cela ne signifie pas nécessairement que je vais récompenser votre comportement. Peut-être ou pas du tout.

Dans votre hâte à créer une première bonne impression ne faites pas quelque chose que vous n’êtes pas enclins à faire sur une base régulière.

Sachez ce que vous voulez, présentez-vous comme qui vous êtes vraiment, soyez clairs sur comment vous voudriez être traités et soyez honnêtes sur ce qui fonctionne ou pas pour vous.

comment aider le groupe à atteindre un consensus quand ils ne sont tout simplement pas d’accord ?

Le 4 octobre 20104 octobre 2010 par mopertodans forum de discussion2 commentaires

How Do You Help the Group Reach Consensus When They Simply Don’t Agree? Par Dana Brownlee

Le Problème : estimez-vous jamais que vous élevez un groupe de chats sauvages au lieu de mener une réunion parce que les membres de votre équipe ne peuvent pas simplement tomber d’accord ? Eh bien, réconfortez-vous de savoir que ce problème commun est le lot de la plupart des facilitateurs de réunion à un moment ou un autre. En effet, si votre groupe n’est pas d’accord avec véhémence (mais avec respect), c’est un signe de conflit sain. Félicitations ! Vous êtes probablement en chemin vers quelques grandes idées et solutions! Malheureusement dans notre rôle de facilitateur de réunion, nous devons souvent guider le groupe vers une décision de consensus et souvent cela ne semble pas possible. La bonne nouvelle est que le fait d’atteindre une décision de consensus ne signifie pas qu’une session de deux heures doive transformer en session de deux semaines, ou pire, un coup d’arrêt réel. Explorons quelques astuces à utiliser la prochaine fois que vous faîtes face à cette situation.

Considérez ces suggestions

Souvenez-vous d’abord que le consensus ne signifie pas que chacun obtient exactement ce qu’il veut. Il signifie en fait que chacun peut vivre avec la décision et la supporter à l’extérieur de l’équipe.

Développez une règle du jeu avec l’équipe sur comment le groupe prendra ses décisions AVANT que vous ne deviez prendre ces décisions. Si le groupe a déjà établi un accord sur le processus de décision, prendre les décisions suivantes devient beaucoup plus facile (et moins chargé émotionnellement). Par exemple, si le groupe a déjà convenu des critères de décision et du processus de sélection avant de commencer la discussion de quel salarié recevra la récompense du « Salarié de l’Année », cette décision devient soudainement beaucoup plus facile.

Quand vous vous enlisez dans le désaccord, séparez les secteurs d’accord et de désaccord. Identifiez et documentez clairement les secteurs d’accord pour continuer à faire avancer le groupe. Pour les secteurs de désaccord, clarifiez sur quoi porte le désaccord. Par exemple : Mike, il semble que toi et Beth reconnaissez tous les deux que le temps de cycle actuel de 5 jours est trop long. Il semble que le secteur de désaccord porte seulement sur la réduction nécessaire. Mike propose 2 jours tandis que Beth pense que 1 jour est une meilleure cible, donc nous avons une différence d’avis de 1 jour. Est-ce correct?

Parfois nous pouvons ne pas être d’accord parce que nous n’avons pas assez d’informations et nous raisonnons à partir de suppositions mal informées. Invitez les parties prenantes clefs à participer à la discussion (par exemple : Les experts en informatique, les membres de l’équipe de direction, les ressources humaines ou des experts financiers, etc.). Ils peuvent souvent apporter un éclairage sur des problèmes critiques et aider le groupe à déterminer plus facilement la meilleure alternative.

Si vous avez tendance à penser que le groupe peut chicaner sur des différences insignifiantes, envisagez de suggérer qu’ils conduisent le reste de la réunion debout (jusqu’à ce qu’une décision soit atteinte). Cette technique est parfois utilisée comme une méthode « qui sort des habitudes » pour encourager la brièveté et l’esprit de compromis.

Utilisez une technique de facilitation qui encourage la prise de décisions collaborative (par exemple le diagramme d’affinité, le « dot voting », etc.). Ces techniques offrent typiquement à chaque participant un certain nombre de votes; puis les participants votent simultanément et l’option recevant le nombre de votes le plus haut est en général choisie.

Si vous sentez que les désaccords peuvent être dus à des conflits de personnalité ou autres raisons personnelles, abordez ces questions en aparté dans une configuration plus privée avec les individus impliqués.

partagez ce billet avec vos amis, collègues et relations professionnelles

Hello,

please check out the article related to leadership in PM Network October 2010 edition.

I’ve been interviewed and I contributed to this article together with many other PMs (starting page 74 onwards)

I’m famous ! 🙂

Cheers, Michel.

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

Comment devenir PgMP® ?

Critères d’admission

Les étapes

1 – Formulaire d’application en ligne sur le site du PMI® : www.pmi.org

2 – l’Examen

3 – 360°

Conserver sa certification

partagez ce billet avec vos amis, collègues et relations professionnelles

Les organisateurs d’événements attendent des intervenants qu’ils ou elles :

partagez ce billet avec vos amis, collègues et relations professionnelles

Earning PDUs is a Breeze Écrit par John Reiling

Avoir des objectifs Personnels et Professionnels est la Clé

Préparer un Plan d’exécution

Il s’agit de planification

Il s’agit d’exécution

Catégorie 1

Catégorie 2

Catégorie 3

Catégorie 4

Catégorie 5

Un Appel à l’Action pour les PMPs

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

Multitasking Gets You There Later article de Roger Brown

Une Perspective Différente

Les coûts du Multitâche

Multitâche Agile ?

Neuroscience de Multitâche

La recherche suggère beaucoup de façons dont le multitâche est inefficace ou même nuisible.

Monotâche pour Équipes Agiles

Monotâche pour Organisations

La Variété est l’Épice de la Vie

Conclusion

partagez ce billet avec vos amis, collègues et relations professionnelles

1) Notre approche se concentre-t-elle sur les bons critères ?

2) Avons-nous les bonnes pondérations pour chaque critère ?

3) Avons-nous le bon mélange de critères ? Est-il équilibré selon différentes perspectives?

4) Nous concentrons-nous sur la bonne comparaison de projets et leur inter-relation et l’impact de choisir un projet par rapport à un autre ?

5) Avons-nous la bonne Classification de projet?

6) Avons-nous la bonne gouvernance de PPM, avec les bonnes personnes engagées au bon niveau ?

partagez ce billet avec vos amis, collègues et relations professionnelles

Établissez des jalons significatifs

Découpez le Projet en phases de 9 mois ou moins

Managez et Comprenez la Longueur « du trajet »

partagez ce billet avec vos amis, collègues et relations professionnelles

La réunion a commencée depuis 10 minutes.

Que faire pour sensiblement améliorer votre téléconférence ?

partagez ce billet avec vos amis, collègues et relations professionnelles

Requirements Hurried . . . Project Buried (exigences précipitées, projet enterré) de G Chandrashekar

1. Ne pas bousculer cette étape

2. Détails. Vous ne pouvez pas en avoir trop

3. Comprendre le business, pas les besoins exprimés

4. Tout documenter

5. Impliquer les utilisateurs. Les utilisateurs réels

6. Aller les voir travailler

7. Chercher le « chemin malheureux »

8. Aller dans les coulisses

9. Trouver les documentations

10. Construire un nouveau système, ne pas copier l’ancien

11. Construire des besoins ou des limitations ?

12. Voir les rapports et les gens qui les utilisent

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.

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

Fabrication d’un « burn down chart » sous Excel

Étape 1 : Arrangez les données pour faire un « burn down chart »

Étape 2 : Faites un bon vieux graphique à lignes

Étape 3 : Ajoutez les valeurs complétées quotidiennes (Daily Completed) pour compléter le « burn down chart »

Étape 4 : Ajustez le formatage et des couleurs

Téléchargez le modèle “burn down chart”

partagez ce billet avec vos amis, collègues et relations professionnelles

Dans son billet « Agile moving forward », Ryan Endres explique comment il a mis en place un environnement collaboratif basé sur microsoft sharepoint pour documenter et suivre son projet.