la capacité des chefs de projet à savoir tirer les leçons de leurs projets et surtout à les utiliser ensuite est apparue comme une habitude prise par les meilleurs.
Une vidéo pédagogique conçue et réalisée par Roberta Faulhaber et Live Productions qui explique les avantages de la facilitation graphique pour des réunions plus efficaces, productives, et engageantes.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les retours d’expérience doivent être documentés le plus en détail et le plus tôt possible.
L’expérience est la clé d’une anticipation réussie.
Le partage de bonnes pratiques est critique à l’amélioration de tous.
Les leçons apprises donnent un plan de route pour des investissements qualité.
Il faut une consultation systématique des leçons des projets passés lors du lancement de nouveaux projets.
Pour aller plus loin sur ce sujet des leçons apprises, voici les pointeurs vers plusieurs billets sur cet aspect critique dans le management, leadership et dans les projets.
Les trois petits cochons sont une activité de rétrospective amusante qui utilise l’histoire des 3 petits cochons pour favoriser une conversation sur les améliorations pour obtenir de plus solides structures.
Animation de l’activité
1. Dessiner et expliquer aux participants les 3 colonnes :
La maison de paille – que faisons-nous qui tient à peu près debout, mais pourrait se renverser à tout moment ? (Par exemple « notre script de déploiement est très manuel et prône à l’erreur : nous pourrions très facilement casser la plateforme de production « )
La maison de bois – que faisons-nous qui est assez robuste, mais pourrait être amélioré ? (Par exemple « nos tests automatisés sont assez bons, mais parfois ils échouent sans raison et nous devons les exécuter à nouveau, ce qui est source de douleur »)
La maison de briques – que faisons-nous qui est solide comme un roc ? (Par exemple « notre déploiement automatisé et mise en production n’ont jamais échoué. Ça roule. « )
2. Demander aux participants de partager leur idées sur des post-it et de les placer dans l’une des trois colonnes
3. Filtrer et discuter en groupe sur les mesures à prendre.
Cette activité a été partagée par Steve Wells. C’est une activité géniale et amusante, particulièrement quand elle met en scène un bon dessin des trois cochons avec leurs maisons.
Microsoft est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Nous commençons nos projets avec une petite équipe principale, la « core team », mais comme nous nous enfonçons de plus en plus dans le projet, nous ajoutons des membres à l’équipe pour supporter des activités de planification et de livraison. Alors comme des pans de travail sont complétés, la taille d’équipe se réduit jusqu’à ce que nous atteignions la clôture de projet et revenions à l’équipe principale de départ. Sur de grands projets, à phases multiples, l’expansion et la contraction d’équipe arrivent fréquemment, mais même avec des projets beaucoup plus petits, il est commun que des membres de l’équipe partent avant que le projet lui-même ne soit complété. Parfois, ceci pourrait être le résultat de la complétude des activités leur étant assignées, mais ce peut aussi être causé par des facteurs externes comme leur réquisition par un projet plus prioritaire ou une décision financière de déplacer leur tâches vers une ressource moins onéreuse.
1. Reconnaissez-les publiquement
J’espère que ce n’est pas la première fois que vous aurez l’occasion de le faire, mais il est particulièrement critique que vous les remerciez publiquement en vous référant à leurs accomplissements spécifiques avant qu’ils ne quittent le projet. Ceci garantira qu’ils partiront sur une note positive et manifestera aussi à l’équipe que vous êtes conscients du travail acharné qu’ils fournissent.
Si les budgets et la politique de l’organisation le permette, remettez une carte cadeau au membre de l’équipe sur le départ ou un autre petit témoignage de remerciement avec une carte de félicitations signée par l’équipe entière. Vous pourriez aussi envisager d’envoyer un mot de remerciement à leur manager pour renforcer la relation positive que vous voudriez construire avec cette partie prenante et fournir des éléments pour l’évaluation de performance du membre de l’équipe.
2. Sollicitez leur retour d’information
Ma première remarque sur les leçons de projet est que dans beaucoup d’organisations nous attendons jusqu’à la fin d’un projet pour acquérir cette connaissance. Ce jalon pourrait arriver des mois après qu’un membre de l’équipe soit parti avec des leçons potentiellement de grande valeur dans leurs bagages!
Prenez le temps de demander au membre de l’équipe quelle a été leur expérience pour entrer sur le projet, ce qu’ils ont aimé ou pas dans leurs tâches et s’il y avait une chose qu’ils voudraient voir changer dans les pratiques de travail de l’équipe quelle serait-elle. En sollicitant ces informations pendant que le projet est en cours vous avez l’occasion d’éliminer des obstacles qui pourraient être irritants pour d’autres membres de l’équipe.
3. Facilitez le transfert de connaissance
Combien de fois avez-vous quitté un projet en cours seulement pour vous retrouver rappelé pour fournir des jours ou même des semaines de support par la suite ? Ceci est le plus souvent causé par une pauvre planification et exécution de la transition.
Nous avons tendance à penser à la planification de la transition quand un membre de l’équipe part avant que son travail assigné n’ait été complété, mais même quand quelqu’un part après que son périmètre ait été délivré, il y a toujours besoin de passer ses connaissances à un autre membre de l’équipe ou à l’équipe dans son ensemble. Ceci pourrait inclure la connaissance d’où leurs produits et autres livrables sont stockés, le transfert des contrôles d’accès à leurs documents à d’autres et les listes de contact de toutes les parties prenantes ou experts du sujet à l’extérieur de l’équipe projet avec lesquels ils avaient été fréquemment en relation.
La clôture d’une phase ou du projet entier implique d’habitude une certaine formalité lorsqu’il s’agit de faire passer à l’équipe la dernière phase de l’échelle de Tuckman.
Mais quand les membres de l’équipe quittent nos projets en milieu de phase, nous devrions exécuter les trois tâches de transition ci-dessus afin d’éviter les conséquences du risque mentionné par Dave Mustaine
» Passer à autre chose est une chose simple, ce qui reste derrière est difficile. «
Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Une transmission de projet réussie exige bien plus que de remettre les clés et les informations de connexion au nouveau chef de projet. Un chef de projet devrait suivre ces six étapes pour compléter avec succès la transmission de son projet.
Cet article, au départ écrit pour des entrepreneurs, recèle quelques conseils tout aussi utiles pour les chefs de projet.
Le livre sur Amazon
En effet, nous sommes souvent confrontés à la nécessité de « vendre » notre projet aux membres de nos équipes, à nos diverses parties prenantes et au management. En particulier lors de la justification et du lancement du projet mais également lors de changements organisationnels, à l’arrivée de nouvelles parties prenantes, pour accueillir de nouveaux clients…
Une des parties les plus importantes d’une rétrospective réussie est son « lancement ». Le facilitateur doit créer un environnement dans lequel l’équipe se sente à l’aise pour parler devant les autres de n’importe quel sujet. C’est le moment où l’exercice « la marque de voiture » pourrait vous aider.
Que pouvez-vous espérer de cet exercice ?
C’est une bonne entrée en matière pour permettre aux membres de l’équipe de partager leurs sentiments sur comment est allé le sprint. Ils peuvent montrer leurs ressentis sans avoir besoin d’exprimer ouvertement leur avis. Quand les membres de l’équipe sont nouveaux, peut-être hésitent-ils à parler franchement, c’est pourquoi ceci est un excellent exercice à utiliser dans cette situation.
Quand utiliserez-vous cet exercice ?
Comme expliqué ci-dessus, l’exercice devrait être utilisé au début pour préparer le terrain pour que l’équipe puisse commencer la rétrospective. Ceci est un bon moyen de révéler l’avis des personnes, permettant à tout le monde d’avoir une compréhension partagée de ce que pensent les autres.
Comment l’exécutez-vous ?
Au début de la rétrospective, assurez-vous que tout le monde se sent confortable, posez-leur après cela une question simple : « si vous pensez à ce sprint comme à une marque d’une voiture, quelle voiture choisissez-vous ? ».
Par exemple, je choisis une Ferrari ou une Maserati si le sprint est allé très bien. Si le sprint avait des hauts et des bas, je choisirais une Fiat ou une Skoda. Donnez à une équipe 2-3 minutes pour réfléchir à leur marque.
Ensuite, demandez à chaque membre de l’équipe de révéler « sa voiture ». Laissez-les dessiner sur un flipchart ou l’écrire sur un post-it. À ce moment-là, ne leur demandez pas de justifier leurs choix. Permettez aux membres de l’équipe de voir quel est le choix de chacun. Ceci crée un sentiment global sur où en est l’équipe. Puis, demandez-leur de penser à la voiture de leurs rêves et donnez-leur 10 minutes pour réfléchir à ce qu’ils changeraient dans le sprint passé pour avoir « la voiture de leur rêve ».
Normalement, les équipes trouvent beaucoup d’idées différentes, mais ces idées sont d’habitude liées à des problèmes partagés. Demandez alors à l’équipe de voter pour choisir le problème le plus critique et important auquel l’équipe s’attaquera dans le prochain sprint.
Cet exercice utilise une marque de voiture, mais vous pouvez utiliser d’autres objets significatifs pour vous. L’équipe n’a pas besoin d’être co-localisée pour exécuter cet exercice. Il est applicable aux équipes géographiquement distribuées en utilisant divers outils de partage virtuel.
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
1. Portez-vous volontaire pour prendre les minutes d’une réunion importante
Assurez-vous de trouver ou créer un modèle qui capture la liste des participants, la date et la durée de la réunion, l’ordre du jour, les actions qui ont été agréées, les tâches assignées à chaque participant et leurs dates de fin, les problèmes non résolus ainsi que la date et heure de la prochaine réunion. En vous portant volontaire pour cette mission, vous fournirez un document clé à l’équipe de projet sur lequel ses membres peuvent se baser pendant tout le projet.
2. Vérifiez la bonne compréhension
A la conclusion et documentation du contenu du projet, questionnez le sponsor et les parties prenantes pour vous assurer qu’ils comprennent vraiment pour quels contenus ils signent et « l’engagement » nécessaire pour réaliser le projet. Ceci vous donnera un aperçu des “Changements de Contenu (/périmètre)” qui risquent de surgir avant que ces demandes de modifications ne surviennent. Cela augmentera aussi votre compréhension du processus de projet et votre stature par rapport aux autres chefs de projet.
NQI est Partenaire de DantotsuPM
3. Faites le forcing sur les leçons apprises
Dès 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.
4. Prenez en charge un problème majeur
Image courtesy of artur84 at FreeDigitalPhotos.net
Identifiez un problème qui semble diviser les membres de l’équipe de projet ou les parties prenantes et managez-le en enregistrant les actions majeures et décisions prises par l’équipe et les parties prenantes. Au moment approprié dans le projet, quand il apparaît que l’équipe projet ou les parties prenantes (ou les deux) se trouvent dans une impasse ou ont atteint un point délicat, sortez votre résumé des actions agréées et décisions prises et passez-les en revue avec ce groupe combiné. Certains peuvent ne pas apprécier d’être confrontés avec les faits, d’autres peuvent ne pas être d’accord avec vos « faits » ou votre interprétation, mais personne ne pourra dénier l’harmonie qui en résultera quand chacun commencera à voir les perspectives et points de vue des autres. Personne ne critiquera le fait qu’un observateur « raisonnable et réaliste » ait porté ces points de vue à leur attention.
Beaucoup d’attention est portée au « Manifeste Agile » et bien qu’il soit une composante importante de Agile, ce n’en est pas toute la substance. Il y a 12 principes directeurs en plus des 4 composants principaux du manifeste. Jetons un rapide coup d’œil à chacun d’entre eux et voyons combien ils affectent comment nous percevons et implémentons les pratiques Agiles…
1. Notre priorité la plus haute est de satisfaire le client par la livraison rapide et continue de logiciel de valeur.
Ceci est l’aspect le plus important d’Agile qui doit être compris et adopté comme une partie de la culture de toute organisation qui veut être « Agile » : le client et l’utilisateur final sont le focus ultime du processus tout entier, du commencement jusqu’à la fin. Le client est le juge du succès ou de l’échec d’un produit ou d’une fonctionnalité, pas la société ni ses parties prenantes. Le client est celui avec les problèmes que nous adressons et comme tel il doit être partie intégrante du processus de développement de produit du commencement à la livraison.
Ignorer vos clients jusqu’à ce que votre produit soit prêt à être expédié est l’anti-modèle Agile numéro 1 dans le monde.
2. Accueillez avec bienveillance les demandes d changement, même tard dans le développement. Les processus agiles exploitent le changement pour donner un avantage compétitif du client.
La deuxième partie la plus importante de Agile est en fait… …de faire preuve d’agilité. N’importe quelle organisation qui investit lourdement dans la définition en amont, la conception et la définition des besoins n’estPas Agile…et ne fait certainement pas preuve d’agilité. Tout le point de l’agilité est que vous pouvez vous accommoder d’importants changements de besoins à n’importe quel point du processus et toujours livrer quelque chose qui est utile pour le client et résout un ou plusieurs de leurs problèmes. Des processus agiles s’appuient sur la Priorisation et non par la Négociation de contrat pour atteindre le succès. Quand de nouveaux besoins surviennent, ils ne sont pas soumis à de lourds et détaillés processus de management des changements. Ils sont plutôt ajoutés à la pile de tout le reste à faire et évalués tout simplement comme une autre tâche ou histoire utilisateur déjà dans le processus.
Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin
Penser que les choses sont totalement ou presque entièrement définies à l’avance est un autre anti-modèle Agile dont beaucoup de sociétés souffrent fréquemment.
3. Livrez souvent (entre deux semaines et deux mois) du logiciel qui fonctionne avec une préférence pour les fréquences les plus rapides.
Il y a plusieurs choses dans ce principe. D’abord du logiciel qui marche est le but du processus à chaque étape, ensuite le travail devrait être itératif et s’améliorer à chaque livraison et, finalement les itérations qui sont engagées devraient être les plus courtes possible. Si vous travaillez sur un projet qui progresse pendant six mois sans vérifier les résultats intermédiaires avec le client (ou son représentant), vous n’êtes pas Agiles. Si vous travaillez sur des itérations d’une semaine, mais ne livrez pas quelque chose qui résout au moins un problème client à chaque itération, vous n’êtes pas Agiles. Les itérations agiles doivent être assez longues pour livrer un logiciel qui fonctionne et assez courtes pour vous assurer que ce que vous livrez résout bien dans les faits des problèmes clients.
CertYou est partenaire de DantotsuPM
Travailler itérativement ne signifie pas nécessairement que vous êtes Agiles; l’itération est importante, mais livrer un logiciel qui fonctionne l’est tout autant.
4. Les gens du métier et les développeurs doivent travailler ensemble quotidiennement pendant tout le projet.
La collaboration et les interactions entre les gens sont critiques au succès de toute organisation Agile. Les silos et le « jeté de besoins par-dessus le mur » sont contre-productifs aux approches Agiles, comme l’est de segmenter votre organisation entre les gens « du métier/business » et les « techniciens ». Tout le monde du côté « métier/business » devrait être prêt, consentant et disponible pour fournir autant de support que possible aux équipes « techniques » et vice versa. L’idée séculaire qu’il y a une certaine différence inhérente entre la façon dont « l’activité business » devrait être exécutée et la façon dont « la technologie » devrait l’être est entièrement artificielle et contre-productive dans un âge d’innovation rapide et de livraisons encore plus rapides.
Décourager la collaboration ou encourager le « silotage » des efforts est un anti-modèle Agile qui persiste dans trop de cultures d’entreprise.
5. Construisez les projets autour de personnes motivées. Donnez-leur l’environnement et le support dont elles ont besoin et faites leur confiance pour faire le travail.
Agile valorise les personnes en tant que personnes et les équipes en tant qu’équipes. Les gens ne sont pas des rouages interchangeables que vous pouvez aléatoirement déplacer d’un projet à un autre et vous attendre à ce qu’ils excellent continuellement. Les individus sont motivés par des choses différentes et dans une vraie approche Agile nous exploitons ce qui motive individuellement les membres de notre organisation pour créer des équipes avec ces individus motivés qui sont intrinsèquement motivés pour réussir. Agile déboute de l’idée que la récompense extrinsèque fournit des résultats exceptionnels et se concentre plutôt sur l’assurance que les individus aient la motivation, l’environnement et les outils dont ils ont besoin pour réussir tout seuls. Il n’y a aucune approche de type « la carotte et le bâton » dans Agile. Il y a des problèmes à résoudre pour les clients qui sont intéressants et fascinants et qui sont résolus par des personnes qui ont l’intérêt nécessaire et la motivation intrinsèque pour les résoudre.
NQI est Partenaire de DantotsuPM
Attendre des gens d’être performants simplement parce qu’ils sont membres « d’une équipe » et non pas parce que cette équipe partage la motivation intrinsèque de réussir est un anti-modèle extrêmement commun dans les grandes organisations.
6. La méthode la plus efficace et effective de transmettre des informations dans une équipe de développement est la conversation en face à face.
La méthode séculaire d’avoir un unique expert du sujet qui écrit tout qu’il veut avoir et le remet aux développeurs comme « une liste à exécuter » de besoins est hérétique aux approches Agiles. Des personnes différentes pensent et communiquent différemment et le texte écrit est l’une des pires façons d’exprimer que vous essayez de dire. Au pis-aller, c’est vague et difficile à déchiffrer pour la personne qui ne l’a pas écrit; au mieux, c’est un document clinique, stérile qui remplace le sentiment par la précision. Si le but est d’exprimer la douleur que ressent le client et motiver les équipes à exceller dans leur job parce qu’elles le veulent, alors aucune de ces approches par des besoins écrits n’aura le résultat que nous désirons. Nous utilisons plutôt des choses comme les Histoires Utilisateur, qui explicitent le problème que nous voudrions résoudre, mais qui permettent à notre équipe de développement d’utiliser sa créativité pour y répondre de la meilleure façon possible.
Même quand nous utilisons des outils pour suivre le travail et communiquer les informations les plus basiques, nous ne pouvons pas oublier que la façon la plus importante de communiquer l’un avec l’autre, indépendamment des rôles, est toujours la conversation en face à face.
7. Le logiciel qui marche est la principale mesure de progrès.
Particulièrement dans le monde des grandes sociétés, nous aimons le concept que tout peut être mesuré, évalué et KPIsé. Nous suivons les revenus, des points d’histoire, la vélocité, la consommation, les nombres d’erreurs découvertes, Ad Nauseum. Pourtant nous oublions souvent que ce que nous essayons vraiment de faire est résoudre des problèmes pour les clients. Et aucune de ces mesures n’indique combien de valeur nous apportons en réalité ni si nous résolvons vraiment des problèmes clients. Le but final de chaque itération devrait être du logiciel qui marche, qui fait quelque chose que nous pensons être de valeur. Sans cela, c’est un échec. Quoi que ce soit de plus que cela est du glaçage sur le gâteau. Les équipes Agile se mesurent elles-mêmes sur si elles apportent réellement de la valeur et si elles créent vraiment quelque chose qui marche la fin de chaqueitération.
Répétons ceci : la vélocité n’est pas la mesure du progrès. La consommation n’est pas la mesure de progrès. Les points d’histoire ne sont pas la mesure de progrès. La capacité n’est pas la mesure de progrès. Les délais ne sont pas la mesure de progrès. La seule chose qui importe est combien vous créez de logiciel qui marche.
Campana & Schott est partenaire de DantotsuPM
8. Les processus agiles font la promotion du développement durable. Les sponsors, les développeurs et les utilisateurs devraient pouvoir indéfiniment tenir une allure constante.
Voir les billets sur l’initiative #ecoPMI
Il y a cette idée fausse dans le monde, tenue tant par les développeurs que par des hommes d’affaires, que Agile signifie aucune documentation, que Agile veut dire faire quoi que vous ayez besoin de faire pour atteindre un but, que Agile signifie changer les priorités et équipes rapidement pour assurer une production maximale, que Agile rime avec imprévisibilité et manque de prédictibilité. Le fait est, l’un des buts principaux d’Agile est créer un environnement de prévisibilité, de stabilité et une allure constante et acceptable de développement de produits qui dure indéfiniment. Il n’y a rien dans les principes Agile qui écarte de créer des planning (quoique ces plans portent un peu d’incertitude !) ni d’être capable de prévoir quand quelque chose pourrait être livré. Au contraire, il n’y a rien dans les principes Agile qui s’attend à ce que des développeurs s’engagent dans des comportements de pression exagérée. En fait, de tels comportements sont de bien des façons antithétiques aux concepts Agiles : si votre équipe doit travailler beaucoup trop durement pour livrer quelque chose, vous avez manqué en amont à vos devoirs de priorisation efficace des Histoires Utilisateur.
Aucune vraie pratique Agile ne devrait aboutir à de l’épuisement, des périodes critiques, ni une incertitude constante et prolongée. Les anti-modèles aboutissent à ces comportements contradictoires.
9. L’attention continue à l’excellence technique et à la bonne conception améliore l’agilité.
Des équipes vraiment agiles ne rassemblent pas à la va vite de mauvais morceaux de code pour l’appeler « bon ». Elles prennent le temps et mettent les efforts nécessaires pour comprendre ce qu’elles essayent de réaliser, comment elles pensent pouvoir résoudre les problèmes et décomposer les choses en assez petits « morceaux » de travail pour à la fois itérer sur le problème et livrer des solutions potentiellement exploitables à chaque étape du projet. La majorité de ce travail se produit avant que les équipes ne s’engagent à faire le travail. Il y a là du pré-travail pour parler approches, pour discuter architecture et s’engager dans des discussions avec des représentants du métier, des parties prenantes et les équipes techniques. Nous nous référons souvent à ceci comme à des sessions de démarrage ou de préparation d’arriéré de produit mais Agile ne devrait jamais être une excuse pour la mauvaise qualité ou une conception erronée.
La conception erronée et de faibles standards aboutissent à de pauvres solutions qui ne répondent pas vraiment aux besoins clients; c’est un facteur de ralentissement, pas un facteur d’accélération.
10. Simplicité, l’art de maximiser la quantité de travail non fait, est essentielle.
Beaucoup trop de personnes lisent ceci de la mauvaise façon et limitent ainsi leur capacité à totalement s’engager dans des pratiques Agiles fortes. Simplifier vos buts, vos histoires, votre travail et tout le reste est un processus qui commence par l’opposé : une très large compréhension de ce que sont les buts et de comment ils pourraient être atteints. Le résultat de tels efforts n’est pas nécessairement un projet plus petit, mais des incréments plus petits et plus simples qui peuvent s’additionner en quelque chose de très grand et qui peuvent aussi indirectement réduire les buts globaux. Le plus grand obstacle est ici que lesimple est plus difficile que le complexe, particulièrement quand les gens s’engagent dans des séances de remue-méninges, ce qui arrive souvent avec des équipes techniques. Résolvez le problème d’abord, itérez ensuite par petits morceaux.
« Rendez chaque détail parfait et limitez le nombre de détails à perfectionner. » Jack Dorsey
11. Les meilleures architectures, besoins et conceptions naissent d’équipes auto organisées.
Le mot clé est ici « naissent ». Quand vous réunissez les bonnes personnes et que toutes sont alignées vers les mêmes buts, certaines choses se produisent. D’abord, elles se tiennent naturellement responsables, parce qu’il y a un sentiment intrinsèquede camaraderie et de but commun. Deuxièmement, Elles se supportent et en même temps se défient pour assurer que le résultat final respecte non seulement leurs attentes individuelles, mais aussi leurs attentes collectives qui sont presque toujours plus élevées. Et finalement, elles améliorent le tout par la collaboration : la valeur de n’importe quelle équipe auto-organisée est au moins 2 fois plus importante que la somme de ses parties individuelles. Le facteur clé est ici auto-organisation, qui peut être dure à vendre dans beaucoup d’organisations, mais les meilleures équipes ne sont pas celles assemblées par un cadre intermédiaire, ce sont plutôt des groupes de personnes qui ont choisi de s’aligner vers un but commun.
Les personnes qui travaillent vers un but commun parce qu’elles le veulent seront toujours plus efficaces, plus fortes et plus fiables que des équipes travaillant ensemble parce qu’on leur a dit de le faire.
12. À intervalles réguliers, l’équipe réfléchit à comment devenir plus efficace, puis règle et ajuste son comportement en conséquence.
Get the book on Amazon
Dans presque chaque organisation que j’ai observée face au défi d’implémenter les pratiques Agile, la plus grande chose qu’elle loupe est l’importance de l’amélioration continuelle ou continue. Agile a ses origines dans des concepts industriels LEAN : la valeur de l’individu, la primauté du résultat sur le processus et, plus important encore, le besoin de constamment mesurer, ajuster et améliorer comment vous faites ce que vous faites. Toute équipe qui veut ne pas s’engager dans les rétrospectives et les revues d’équipe avec leurs parties prenantes après chaque itération risque la stagnation et les anti-modèles parce qu’elle ne les voit jamais arriver. Beaucoup d’équipes voient ces sessions comme contre-productives, des pertes de temps, des exercices « soft skills » qui consomment seulement de leur temps d’exécution. Mais la plupart des équipes les évitent simplement par crainte (et le rationalisent comme elles le peuvent): la crainte d’être sur la sellette, la crainte d’accepter la responsabilité, la crainte de changement. La vérité vraie est que quand elles sont exécutées correctement, elles peuvent être les réunions les plus enrichissantes dans lesquelles les équipes s’engageront. Elles sont destinées à pousser les gens à constamment s’améliorer et être plus efficaces et il n’y pas de bonne raison de ne pas s’engager dans ces discussions.
L’absence de « regarder derrière soi » profondément et honnêtement pour évaluer comment une équipe avance et où elle peut s’améliorer est un anti-modèle fatal au succès de Agile sur le long terme.
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
« Je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès », Rebecca Winston
J’avais publié ce billet il y a 6 ans et il me semble toujours autant d’actualité. Aussi me suis-je permis de le reprendre pour en améliorer la forme et clarifier certains messages clés.
Certaines des leçons que j’ai appliquées, je les ai apprises au prix d’un certain nombre de cicatrices et de l’observation d’autres de chefs de projet que j’ai rencontrés ou avec lesquels je suis en relation. Il n’y a aucune formule magique ni nec plus ultra; Seulement quelques leçons relativement simples qui démentent la difficulté avec laquelle elles sont mises en œuvre.
D’abord, je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès. Je ne suis pas ni n’ai rencontré non plus le chef de projet de redressement qui connaisse en fin de compte la réponse sur comment transformer un projet dysfonctionnel ou en échec. Cependant, j’ai appris de nombreuses leçons.
1. Croyez en vous.
Notez bien que je n’ai pas dit croire que vous avez toutes les réponses parce que vous ne les avez pas. Mais vous devez croire sincèrement que vous pouvez faire le job. Si vous ne le croyez pas, qui devrait croire en vous, qui vous donnera une apparente confiance, un sens de la direction et un objectif ?
2. Ne dénigrez pas votre prédécesseur.
Vous faites face à plusieurs pièges si vous vous engagez dans la diffamation du chef de projet précédent. On ne sait jamais qui dans l’équipe peut être leur ami et peut répéter vos déclarations à l’ancien chef de projet. Certaines de ces déclarations peuvent être vraies, d’autres peuvent seulement refléter votre opinion et certaines peuvent s’avérer ne pas être correctes. Vous ne connaissez pas tous les problèmes auxquels s’est confronté le précédent chef de projet. Tout que vous avez sont vos impressions et observations, toutes deux vues par vos yeux et non pas les siens au moment où ils les exécutaient.
De plus, critiquer le chef de projet précédent devant ses pairs peut vous couper d’un précieux réseau. Vous pouvez avoir besoin des autres chefs de projet dans l’organisation pour tester vos idées, questionner la signification et la mise en œuvre de procédures internes, découvrir comment supprimer des points de blocage connus et autres sujets. Beaucoup de ces chefs de projet peuvent vivre dans la crainte d’être les prochains éliminés s’ils trébuchent sur leurs projets.
Oh et n’oubliez pas que la personne qui est votre manager peut avoir été le manager du précédent chef de projet. Il peut même l’avoir embauché. Critiquer le chef de projet précédent peut mettre en doute leur bon jugement.
Campana & Schott est partenaire de DantotsuPM
3. Soyez focalisé sur faire avancer le projet.
La plupart des chefs de projet n’ont pas d’yeux derrière la tête. Les yeux servent à regarder, soit vers l’avant, soit derrière soi. Regarder derrière soi ne change pas le projet et peut vous empêcher de trouver les solutions nécessaires pour résoudre les problèmes. Cela peut aussi vous condamner à revivre dans les risques du passé.
Bien sûr, il faut comprendre ce qui s’est passé et les indicateurs précédents, mais rester dans ce mode ne permet pas à l’équipe d’avancer. En matière de leadership, l’équipe de projet va suivre le chef de projet qui avance sans faire de blocage sur le passé.
4. Croyez en l’équipe.
Ne commencez pas par remplacer des membres de l’équipe par des personnes avec lesquelles vous vous sentez à l’aise. Assurez-vous de bien analyser votre équipe et de lui donner du temps. Les changements causent une mise en doute de l’équipe et les membres restants peuvent devenir moins productifs qu’ils ne l’étaient ou ne pourraient l’être.
Vous, en tant que chef de projet, devez comprendre que, alors que vous vous sentez à l’aise avec de certains individus, le défi d’accroître le pool des talents avec lesquels travailler est plus important. Ils apporteront de nouvelles idées, une perspicacité de projet, la compréhension des risques tant antérieurs que futurs. Certains peuvent avoir des connexions avec des sponsors, des clients, des fournisseurs et autres personnes nécessaires au succès du projet.
Essayez Bubble Plan !
5. Ayez un plan.
La leçon 5 est quelque chose de familier pour la plupart des chefs de projet : avoir un plan. Le plan devrait avoir reçu les avis de l’équipe de projet comme tout plan de projet, mais il devrait être vendu comme le plan vers le succès. Une communication positive est exigée. Le martelage du manque de réussite ou de progrès passés ne réunira pas l’équipe autour de l’esprit de succès. Tant vous-même que l’équipe devez croire que le succès peut être atteint et qu’il le sera dans les paramètres donnés pour le projet.
6. Renégociez.
Vous êtes nouveau et avez de nouveaux besoins, peut-être quelques nouveaux prérequis, ou de nouvelles parties prenantes. N’ayez pas peur de soumettre des demandes de renégociation. Elles peuvent être conduites selon des styles différents, des besoins de communication différents, et avec une compréhension des leçons qui ont été apprises jusqu’à présent sur le projet.
Méta Projets Management est partenaire de DantotsuPM
7. Communiquez, communiquez et communiquez encore un peu plus !
Peut-on le répéter suffisamment ?
Voici une leçon du management de projet en général, mais qui devient encore plus nécessaire dans un projet de rétablissement. Des parties prenantes diverses, incluant les membres de l’équipe, devront être rassurées. Elles devront recevoir plus d’informations au moins pendant quelque temps, une meilleure compréhension des risques et des stratégies de management et d’autres sujet sur lesquels elles peuvent vouloir fournir des informations. De temps en temps, on peut estimer que le chef de projet sur-communique. Ce besoin de sur-communication peut diminuer avec le temps et en fonction du temps restant pour terminer le projet.
8. Soyez créatif.
Le chef de projet de redressement ne peut pas toujours compter ce qu’il a fait dans le passé. Il devra créer de nouveaux rapports, délivrer ces rapports de nouvelles manières, construire un esprit d’équipe différent, utiliser de nouveaux canaux de communication, ou stimuler l’équipe à être plus créative et innovatrice. Parfois cela peut être aussi simple que de ne pas amener des croissants pour la réunion d’équipe, mais de fournir à la place un jambon-beurre au petit-déjeuner. Le bruit créé par un changement aussi simple peut mener à une conversation qui rende le nouveau chef de projet plus réel.
9. Restez en contact avec votre réseau.
Bien sûr, cette recommandation s’applique à tout chef de projet, mais je l’ai trouvée encore plus importante en menant un projet de redressement. Vous aurez besoin d’une caisse de résonance. Il y aura des jours sombres et énervants; des jours où vous sentirez que vous serez le prochain chef de projet à ne pas trouver le chemin vers l’objectif. Votre réseau personnel vous écoutera, vous encouragera et vous offrira peut-être des solutions que vous pourrez vous approprier et utiliser.
10. Ne pensez pas que ce projet sera comme le précédent.
De nouveau une leçon générale de management de projet, mais qui prend une nouvelle signification sur un projet à redresser. Certains aspects peuvent être similaires, mais ces projets n’incluaient pas cette équipe projet, les risques qui ont été rencontrés et leurs impacts, ou les parties prenantes, pour n’en citer que quelques-uns. Déclarer que ce projet est comme un autre que vous avez récemment réalisé transmet à l’équipe un manque de singularité de leur projet et les fera se questionner sur pourquoi ils ont échoué. Hors, les faire se mettre en cause personnellement plus qu’ils ne le font déjà est contre productif.
Il y a ici beaucoup de leçons. Nombre d’entre vous en transportent déjà d’autres dans leurs bagages de PM. J’espère que certaines de celles mentionnées ici peuvent être ajoutées à votre boîte à outils.
De même qu’un chef de projet devrait toujours être en mode apprentissage, votre boîte à outils devrait être en enrichissement permanent.
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
La technique « Un Mot » est un contrôle simple dans l’activité qui permet aux participants de partager leurs sentiments avant d’entrer dans les données et détails de la réunion en elle-même. C’est une bonne ouverture pour une réunion car elle reconnaît les sentiments des personnes et les fait parler dès le début.
Get the book on Amazon
Déroulé de l’activité
Donnez à chaque participant un marqueur et un post-it
Demandez-leur de décrire leur sentiment (dans le contexte de la réunion) en un mot
Groupez les notes sur une grande page
Optionnellement, demandez si quelqu’un veut en dire plus sur leur mot choisi
Décrivez s’il vous plaît < le dernier sprint ou le mois passé ou vos sentiments sur XYZ > en un mot !
Certaines des leçons que j’ai appliquées, je les ai apprises au prix d’un certain nombre de cicatrices, et de l’observation d’autres de chefs de projet que j’ai rencontrés ou avec lesquels je suis en relation. Il n’y a aucune formule magique ni nec plus ultra; Seulement quelques leçons relativement simples qui démentent la difficulté avec laquelle elles sont mises en œuvre.
D’abord, je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès. Je ne suis pas ni n’ai rencontré non plus le chef de projet de redressement qui connaisse en fin de compte la réponse sur comment transformer un projet dysfonctionnel ou en échec. Cependant, j’ai appris de nombreuses leçons.
Première leçon : Croyez en vous.
Notez bien que je n’ai pas dit croire que vous avez toutes les réponses parce que vous ne les avez pas. Mais vous devez croire que vous pouvez faire le boulot. Si vous ne le croyez pas, qui devrait croire en vous, qui vous donnera une apparente confiance, un sens de la direction et un objectif ?
Seconde leçon : Ne dénigrez pas le précédent chef de projet.
Vous faites face à plusieurs pièges si vous vous engagez dans la diffamation du chef de projet précédent. On ne sait jamais qui dans l’équipe peut être leur ami et pourrait répéter vos propos à l’ancien chef de projet. Certaines de ces déclarations peuvent être vraies, d’autres peuvent seulement refléter votre opinion et certaines peuvent s’avérer erronées. Vous ne connaissez pas tous les problèmes auxquels s’est frotté le précédent chef de projet. Tout que vous avez sont vos impressions et vos observations, toutes deux perçues par vos yeux et non pas les leurs au moment où ils les exécutaient.
De plus, critiquer le chef de projet précédent devant ses pairs peut vous couper d’un précieux réseau. Vous pouvez avoir besoin des autres chefs de projet dans l’organisation pour tester vos idées, questionner la signification et la mise en œuvre de procédures internes, découvrir comment supprimer des points de blocage connus et autres sujets. Beaucoup de ces chefs de projet peuvent vivre dans la crainte d’être les prochains éliminés s’ils ont des difficultés sur leurs projets.
Oh et n’oubliez pas que la personne qui est votre manager peut avoir été le manager du précédent chef de projet. Il peut même l’avoir embauché. Critiquer le chef de projet précédent peut revenir à mettre en doute leur bon jugement.
MPM est Partenaire de DantotsuPM
Troisième leçon : Gardez toute votre attention sur faire avancer le projet.
La plupart des chefs de projet n’ont pas d’yeux derrière leur tête. Les yeux servent à regarder soit vers l’avant, soit derrière soi (pas les deux en même temps). Regarder derrière soi ne change pas le projet et peut en fait vous empêcher de trouver les solutions nécessaires pour résoudre les problèmes. Cela peut aussi vous condamner à revivre dans les risques du passé.
Bien sûr, il faut comprendre ce qui s’est passé et les indicateurs précédents, mais rester dans ce mode ne permet pas à l’équipe d’avancer.
En matière de leadership, l’équipe de projet doit suivre le chef de projet qui avance sans se bloquer sur le passé.
Leçon 4 : Croyez en équipe.
Ne commencez pas par remplacer des membres de l’équipe avec des personnes avec lesquelles vous vous sentez plus à l’aise. Assurez-vous de faire votre analyse d’équipe et de lui donner du temps. Les changements causent une mise en doute de l’équipe et les membres restants peuvent devenir moins productifs qu’ils ne l’étaient ou ne pourraient être.
Vous, comme chef de projet, devez comprendre que, alors que vous vous sentez à l’aise avec de certains individus, le défi d’accroître la base des talents avec lesquels travailler est important. Ils apporteront de nouvelles idées, une perspicacité de projet, la compréhension des risques tant antérieurs que ceux à venir. Certains peuvent avoir des connexions avec des sponsors, des clients, des fournisseurs et d’autres personnes nécessaires au succès du projet.
Leçon 5 : Ayez un plan. (quelque chose de familier pour la plupart des chefs de projet)
Le plan devrait avoir reçu les avis de l’équipe de projet comme tout plan de projet, mais il devrait être vendu comme le plan vers le succès.
Une communication positive est exigée. Le martelage du manque de réussite ou de progrès passés ne réunira pas l’équipe autour de l’esprit de succès. Tant vous-même que l’équipe devez croire que le succès peut être atteint et qu’il le sera dans les paramètres donnés pour le projet.
Leçon 6 : Renégociez.
Vous êtes nouveau et avez de nouveaux besoins, peut-être quelques nouveaux prérequis, ou de nouvelles parties prenantes.
N’ayez pas peur d’exercer des demandes de renégociation.
Elles peuvent être conduites selon des styles différents, des besoins de communication différents, et avec une compréhension des leçons qui ont été apprises jusqu’à présent sur le projet.
Leçon 7 : Communiquez, communiquez et communiquez encore un peu plus
Une leçon du management de projet en général, mais qui devient encore plus nécessaire dans un projet de rétablissement. Communiquez, communiquez et communiquez encore un peu plus — peut-on le répéter suffisamment ?
Des parties prenantes diverses incluant les membres de l’équipe devront être rassurées, devront recevoir plus d’informations au moins pendant un peu de temps, une meilleure compréhension des risques et des stratégies de traitement et d’autres sujet sur lesquels ils peuvent vouloir fournir des données.
De temps en temps, on peut estimer qu’ils sur-communiquent. Le besoin de sur-communication peut se réduire dans le temps selon combien il reste de temps pour terminer le projet.
Campana & Schott est partenaire de DantotsuPM
Leçon 8 : Soyez créatif.
Le chef de projet de redressement ne peut pas toujours compter ce qu’il a fait dans le passé. Il devra créer de nouveaux rapports, délivrer ces rapports de nouvelles manières, construire un esprit d’équipe différent, utiliser de nouveaux canaux de communication, ou stimuler l’équipe à être plus créative et innovatrice. Parfois cela peut être aussi simple que de ne pas amener des croissants pour la réunion d’équipe, mais de fournir à la place un jambon-beurre au petit-déjeuner. Le bruit créé par un changement aussi simple peut mener à une conversation qui rende le nouveau chef de projet plus réel.
NQI est Partenaire de DantotsuPM
Leçon 9 : Restez en contact avec votre réseau.
Elle s’applique à tout chef de projet, mais je l’ai trouvé encore plus importante en menant un projet de redressement. Restez en contact avec votre réseau. Vous aurez besoin d’une caisse de résonance. Il y aura des jours sombres et irritants; des jours où vous sentirez que vous serez le prochain chef de projet à ne pas trouver le chemin.
Votre réseau personnel vous écoutera, vous encouragera et vous offrira peut-être des solutions que vous pourrez utiliser et vous approprier.
Leçon 10 : Ne pensez pas que ce projet sera comme le précédent.
De nouveau une leçon générale de management de projet, mais elle prend une nouvelle signification sur un projet de redressement. Ne pensez pas que ce projet sera comme le précédent.
Quelques aspects peuvent l’être, mais beaucoup n’incluent pas cette équipe projet, les risques qui ont été rencontrés et leurs impacts, et les parties prenantes, pour n’en nommer que quelques-uns. Déclarer que ce projet est comme un autre que vous avez récemment réalisé transmettra à l’équipe un manque de singularité de leur projet et les fera se questionner sur pourquoi ils ont échoué. Les faire se mettre en cause eux-mêmes plus qu’ils ne le faisaient déjà est non productif.
Votre boîte à outils doit s’enrichir en permanence.
Il y a ici beaucoup de leçons et nombre d’entre vous en ont déjà d’autres dans leurs bagages de chefs de projets. J’espère que certaines de celles commentées ici peuvent être ajoutées à votre boîte à outils.
De même qu’un chef de projet devrait toujours être en mode apprentissage, votre boîte à outils devrait être en croissance permanente.
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Peu importe combien votre équipe est performante, il y a toujours une opportunité d’amélioraation. L’indice de bonheur est un outil des rétrospectives agile, qui mesure le bonheur des équipes agiles. Luis Gonçalves le partage dans le livre écrit avec Ben Linder « Getting Value out of Agile Retrospectives. »
Le but de cet exercice est d’avoir une représentation graphique des émotions des membres de l’équipe pendant un Sprint. Ce type d’informations aide l’équipe à identifier ce qui affecte sa performance pendant le Sprint. Indépendamment du problème qu’expérience l’équipe, cet exercice les aide à révéler les émotions d’équipe directement en cet endroit.
Quand utiliseriez-vous cette technique ?
C’est certainement approprié pour une équipe qui passe à travers beaucoup d’émotions différentes (positives ou négatives) pendant un sprint. Cela leur bénéficie quand ils veulent en évaluer les conséquences ou quand l’équipe a plusieurs défis dans le Sprint et voudrait comprendre comment ces problèmes sont apparus.
L’indice de bonheur est approprié pour n’importe quelle équipe. Il n’exige pas de niveau de maturité spécifique. L’exercice peut être appliqué tant aux équipes à distance qu’à celles réunies en un même lieu.
Comment le réaliser ?
Prenez une page blanche A4 et quelques post-it. Divisez le papier sur 2 parties/axe – positif et négatif. Graduez ensuite l’axe des abscisses en fonction des jours de sprint.
Il y a 2 façons de conduire l’exercice
Option 1 : L’exercice est fait pendant la rétrospective avec toute l’équipe
Créez de petits groupes de 2-3 personnes. Demandez-leurs de faire une session de brainstorming sur les événements ou les situations qui se sont produites pendant le dernier sprint. Ensuite, demandez aux groupes de créer une représentation graphique des niveaux émotionnels pour les situations sur lesquels ils ont fait du brainstorming. Quand tous les groupes ont terminé, compilez une représentation de tous les groupes sur un seul graphique. N’oubliez pas de mettre une explication sur chaque émotion différente.
Option 2 : L’exercice est réalisé par petits bouts pendant le sprint
Au lieu d’une équipe dessinant le graphique émotionnel, vous laissez chaque individu dessiner un graphe avec son propre niveau d’émotion à la fin de chaque journée de travail. Cette approche permet de s’assurer que tous les événements ou situations sont couverts et aucun n’est oublié.
Les deux options marchent bien!
Vous aurez une belle vue de ce qui est arrivée pendant le sprint. Ces informations aident le facilitateur de la rétrospective dans l’identification des situations qui devraient être répétées et des événements qui causent des problèmes ou le retard de l’équipe.
Microsoft est partenaire de DantotsuPM
De plus, vous pouvez aussi utiliser des techniques d’analyse de cause racine pour identifier les problèmes fondamentaux.
partagez ce billet avec vos amis, collègues et relations professionnelles
La RAM, Responsibility Assignment Matrix, ou Matrice d’Affectation des responsabilités (dont le RACI est un exemple) sert à documenter les rôles et responsabilités de chacun dans le projet.
Si l’on vous pose cette question lors d’un entretien de recrutement ou bien si vous vous la posez au lancement d’un nouveau projet, voici quelques éléments constitutifs importants.
Même si nous n’en sommes souvent pas conscients, nous l’utilisons tous les jours. Dans le domaine professionnel, elle joue un rôle très important. C’est pour cela qu’il est important d’apprendre à bien décoder les expressions du visage, les gestes, etc.
Félicitations – on vient de vous donner l’occasion de manager un projet très novateur – si unique, en fait, que rien de semblable n’a jamais été essayé par votre organisation !
En fait, c’est la méthode qui importe le plus et dans le cas de cette exercice, une approche Agile basée sur des expérimentations rapides et répétées pour trouver la meilleure piste et l’exploiter pleinement.
L’ »étoile de mer » est une excellente activité lors de la collecte de données pour favoriser la réflexion autour des pratiques et de la valeur que l’équipe en retire. Elle aide des membres de l’équipe à comprendre la valeur perçue par chacun sur ces pratiques.
L’étoile de mer divise le tableau blanc en 5 zones :
Continuez à Faire – quelque chose que l’équipe réussit bien et dont vous reconnaissez la valeur.
Moins de – quelque chose de déjà fait; vous y constatez une certaine valeur, mais vous souhaitez le réduire un peu.
Plus de – quelque chose de déjà fait; et dont vous pensez qu’elle apportera encore plus de valeur si davantage utilisée.
Arrêter de Faire – quelque chose qui n’apporte pas de valeur, ou encore pire, qui empêche de progresser.
Commencer à Faire – une nouvelle idée, ou quelque chose vous avez vu marcher auparavant et que vous voudriez mettre sur la table de discussion.
Combien de fois prenez-vous 5 minutes après une réunion ou une session de formation pour réfléchir à ce qui s’est produit ?
Après chaque réunion ou atelier que nous avons avec un client, nous parlons de ce qui est arrivé et prendre du recul. Nous nous demandons quelles sont les choses qui ont bien marché et pourquoi. Nous parlons des choses qui sont allées de travers et essayons de comprendre pourquoi. Ces 5 à 10 minutes sont magiques. Nous y faisons une rétrospection sur comment nous performons comme facilitateurs, formateurs et coach et inventons des façons de nous améliorer.
Quand une session va mal, les gens ont tendance à parler de quoi changer pour la prochaine fois. Mais qu’en est-il d’une réunion moyenne ou vraiment excellente ? Combien de personnes prennent le temps de se demander pourquoi ? Je me demande ce qui pourrait arriver si nous tous le faisions systématiquement ?
Alors, voici le défi que je vous lance : Pendant une semaine, planifiez 5 à 10’ dans votre agenda APRÈS CHAQUE réunion.
Pensez aux questions suivantes et notez une idée ou deux sur la façon d’améliorer une telle réunion la prochaine fois.
1) Est-ce que la réunion était de valeur ? Pourquoi ou pourquoi pas ?
2) Avez-vous prêté attention tout le temps ? Pourquoi ou pourquoi pas ?
3) Tous les autres participants ont-ils prêté attention tout le temps ? Pourquoi ou pourquoi pas ?
4) Quelles parties de la session étaient les meilleures ? Pourquoi ?
5) Quelles parties paraissaient au contraire maladroites ou étranges ? Pourquoi ?
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Bonjour, une fois de plus un article qui m’a particulièrement intéressé dans PM Network, la publication mensuelle du PMI.
Un billet de Hubert Mantel, responsable du centre de compétences en management de projets et programmes chez Airbus
J’y ai appris que la crise sur le projet de construction du A380 a forcé Airbus à reconnaitre la criticité du management de projet pour améliorer l’efficacité. Cette mobilisation a permis de passer en revue les leçons apprises sur les projets et, plus important, en retirer de meilleures pratiques et appliquer toutes celles-ci sur les projets suivants. L’une de ces bonnes pratiques est de travailler de manière plus agile pour accélérer les cycles de conception et de réalisation.
Pour accroitre les compétences en management de projet, un programme de formation interne qui intègre la certification PMI a été conçu et implémenté: Une approche très similaire à ce que j’avais pu observer dans d’autres grandes entreprises (NCR, IBM, Orange…).