La mort de la dérive de contenu (le « scope creep ») et le management de projet Agile

Un seul mot, adaptabilité, résume les avantages du management de projet agile de la manière la plus brève et la plus directe possible.

The Death of Scope Creep  – Agile Project Management

https://www.projectsmart.co.uk/scope-management/the-death-of-scope-creep-agile-project-management.php  par Duncan Haughey

Un seul mot, adaptabilité, résume les avantages du management de projet agile de la manière la plus brève et la plus directe possible. Les organisations qui adoptent l’agilité, qui s’équipent pour s’adapter, sont mieux préparées à s’adapter rapidement aux évolutions fréquentes du marché et aux besoins des clients.

Cependant, d’après mon expérience, la flexibilité de l’agilité peut être une arme à double tranchant. Lorsque vous avez beaucoup trop de latitude sans définitions explicites, la dérive de contenu se produit. Et si vous ne contrôlez pas ce glissement du périmètre, vous vous retrouverez avec des membres de l’équipe fatigués, des clients mécontents et une initiative qui a déraillé !

Qu’est-ce qui motive la dérive de contenu dans les projets agiles ?

Et plus important encore, comment pouvez-vous l’empêcher de mettre en danger vos projets ?

Continuez à lire ce billet pour le savoir.

À quoi ressemble le Scope Creep et comment pouvez-vous le repérer ?

La dérive de contenu se produit lorsque les besoins, les objectifs ou les buts d’un projet changent bien au-delà de ce qui a été promis à l’origine. Chaque fois que ce changement se produit, le projet n’est plus strictement décrit. Et pire encore, les limites des attendus et finalement de la fin du projet deviennent floues.

Savoir à quoi ressemble le scope creep n’aide que si vous savez comment le repérer, et il existe plusieurs façons de le faire. Peut-être introduisez-vous progressivement des choses mineures. Peut-être que les délais sont ignorés. Les délais manqués peuvent amener les membres de l’équipe à mal comprendre leurs devoirs et obligations. Peut-être que votre analyste d’affaires est moins directement engagé.

Si vous apercevez de tels signes, la dérive de contenu met probablement en danger votre projet.

Qu’est-ce que la dérive de contenu et le management de projet agile ?

Dans le management de projet agile, la dérive de contenu fait généralement référence à des changements réguliers, mais non approuvés et non planifiés, qui ont un impact négatif sur les limites du projet. Généralement, en pratique, de tels scénarios signifient que vous mettez constamment en œuvre des changements sans tenir compte de la façon dont le projet en est impacté.

Comment reconnaître cette dynamique ?

Eh bien, ce glissement se manifeste le plus souvent avec l’ajout de nouvelles fonctionnalités et services aux produits. Et cela se produit surtout lorsque de tels ajouts sont effectués sans tenir compte de l’effet sur d’autres limites du projet (par exemple : les délais, le budget, le personnel, la qualité, la sécurité, etc.).

Donc, beaucoup d’entre nous, y compris moi-même, sont conscients du concept de triple contrainte dans le management de projet : Si le contenu d’un projet change, cela peut en affecter la durée et / ou les coûts. Si les effets sur les délais et le budget ne sont pas pris en compte, la qualité va en souffrir. Et c’est ainsi que vous obtenez une dérive de contenu dans le management de projet agile.

Comment éviter que la flexibilité agile ne provoque de dérive de contenu

Pour éviter le glissement de portée associé à la flexibilité requise avec l’agilité, créez votre processus de contrôle des modifications à l’aide d’un tableau Kanban. Une flexibilité incontrôlée peut éventuellement entraîner une dérive de contenu et détourner le projet de son plan initial. Même si votre portée est flexible, restez constamment aligné avec votre plan.

Comment ? Utilisez le nettoyage du backlog (backlog grooming), également connu sous le nom de SCRUM refinement. Cette activité importante est trop souvent négligée.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Le nettoyage du backlog doit être effectué une fois par sprint et implique les éléments suivants
  • Ajout de critères, de contexte, d’urgence, d’estimations ou d’éléments narratifs aux éléments du backlog avant de les pousser vers la production dans un cycle.
  • Suppression des éléments inutiles qui n’offrent plus de sens pour le projet.
  • Harmoniser les objectifs avec la vision pour maintenir un bon périmètre.

Il est essentiel de prendre ces mesures pour minimiser ou prévenir la dérive de contenu. En fin de compte, le nettoyage du backlog permet aux équipes d’accélérer la planification des sprints et d’améliorer l’allocation et la décomposition du travail. Le processus permet essentiellement à un système efficace de management du changement de prendre effet tout en maintenant la flexibilité souhaitée.

Impliquez tous les membres de l’équipe de projet et atténuez les causes du scope creep

Pour éviter la dérive de contenu, impliquez tous les membres de l’équipe. Cela signifie que, même lorsque vos parties prenantes sont satisfaites, n’oubliez pas de vérifier que vos développeurs sont également satisfaits. Informez-les du processus de management des changements et de la façon dont cela les affectera. Ils doivent être des gardiens, des garants de la portée du projet, plutôt que des acteurs du changement.

Gardez également à l’esprit que les membres de l’équipe projet, du moins d’après mon expérience, aiment aider et peuvent accepter d’apporter de gros changements sans passer par la procédure de management des changements.

Pour éviter cela, précisez que tout le monde ne devrait pas accepter d’apporter des modifications à moins d’y être autorisé pour éviter de perturber le calendrier du projet et potentiellement créer une dérive de contenu. Tout membre de l’équipe qui souhaite aider les intervenants doit décrire la procédure de contrôle des changements et se porter volontaire pour aider à enregistrer la demande de changement.

Pourquoi est-il si important d’être si vigilant ?

C’est une question à laquelle il est facile de répondre : la dérive de contenu est un sérieux problème dans les projets agiles, en particulier lorsque le manager de projet, les équipes et les partenaires n’apprécient pas l’effet que les changements peuvent avoir sur l’équipe, le budget et les délais. Heureusement, si vous êtes explicite sur la portée initiale du projet et que vous gérez correctement les modifications apportées à votre plan de projet tout au long de la durée de vie du projet, il est peu probable que la dérive de contenu soit un problème majeur.

Mais pour en être certain, vous aurez toujours besoin d’un système de management de projet efficace qui soit à la hauteur du défi, alors utilisez des outils de management des changements qui vous permettent de documenter de nouvelles modifications et d’évaluer instantanément l’impact de ces modifications.

En tant que manager de projet, vous pouvez hiérarchiser ces modifications et allouer les tâches aux membres de l’équipe à l’aide de solutions telles que ProjectManager. Ensuite, une fois qu’un changement est autorisé, quelqu’un peut s’y atteler immédiatement.

Mettez en œuvre des procédures de management des changements

Que se passe-t-il lorsque quelqu’un essaie d’apporter des changements ? Selon mon expérience, il est naïf de croire que rien ne changera. Mais tous les changements ne sont pas mauvais. Un changement structuré, bien géré et approuvé dans vos projets est tout ce dont vous avez besoin pour éviter la dérive de contenu.

Pour cultiver de tels changements, vous voudrez utiliser une stratégie de management des changements pour décrire les processus de contrôle du changement qui doivent être mis en œuvre et quand le plan de projet doit être mis à jour.

Il est également essentiel de mettre en place une procédure de management des risques qui spécifie la fréquence à laquelle le statut global de votre projet sera évalué. Cette étape vous permet de tenir à jour le registre des risques dont la dérive de contenu.

Et le processus n’a pas besoin d’être intimidant : une procédure de gestion des changements est simple. Fondamentalement, quelqu’un propose un changement via une demande qui est ensuite examinée, acceptée ou refusée. Si elle est acceptée, le changement est inclus dans le plan du projet. L’utilisation des fonctionnalités de management des changements fournies par votre outil de gestion de projet facilitera ce processus.

En fait, l’établissement des mesures correctives implique de déterminer qui évaluera et approuvera les changements car, sans méthode, le changement se produit sans prévenir.

Évitez les changements de DERNIÈRE MINUTE

Enfin, pour éviter toute dérive de contenu, évitez tout changement de dernière minute. Commencez par déterminer la portée de votre projet en fonction des besoins de vos parties prenantes. Ensuite, à l’aide d’une structure de répartition du travail (WBS), générez un plan de travail complet. Le plan de travail est la conséquence de savoir ce que votre projet apportera. Dans le plan, incluez tous les besoins et la façon dont vous y répondrez sous forme d’activités, d’événements et d’objectifs.

Pour vous assurer que vous n’avez rien négligé, faites le lien entre l’échéancier de votre projet et votre processus de management des besoins.

Conclusion & à retenir

Quel que soit le projet, l’évolution des besoins est considérée comme un échec de planification dans le management de projet conventionnel. Aussi, votre étape de planification initiale doit-elle être solide comme le roc, surtout si vous voulez éviter la dérive de contenu.

Si vous ignorez la dérive et n’essayez pas de l’empêcher de se produire en premier lieu, vous risquez de mener votre projet à l’échec et personne ne souhaite cela !

Comment contrôlez-vous la portée de vos projets ?

TOP 3 de février 2022 sur DantotsuPM, le blog du management de projets

Je profite de l’été pour partager sur les billets les plus lus depuis le début de l’année, mois après mois.

1 – #5 exemples fréquents de réunions qui auraient pu être évitées par un simple courriel…

Désormais, vos équipes ne veulent plus rester assises pour des réunions qui pourraient avoir été un simple courriel. Suivez ces recommandations pour éviter cette erreur.

#2 – Le rôle et les compétences d’un testeur dans une équipe agile par Fidaa Berrjeb

En plus de compétences techniques reconnues (les tests d’acceptation, boîte blanche, boîte noire, les automatisations de test …), un testeur agile doit avoir de bonnes compétences interpersonnelles.

CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

#3 – Gestion des écarts dans le management de projets

La gestion des variances par rapport à la base de référence de votre projet est une bonne pratique de management de projet.

Voici quelques conseils pour déterminer les écarts acceptables dans la triple contrainte (portée, temps et coût) de votre projet.

 

Voici 4 types de questions à poser si vous voulez être proactif.

Certaines personnes sont particulièrement proactives, quelles questions posent-elles ?

Questions Proactive People Ask

https://leadershipfreak.blog/2022/02/03/questions-proactive-people-ask/ par Dan Rockwell

Vous êtes foutu si vous ne pouvez pas changer de direction. Un monde turbulent exige que vous restiez très mobile. Mais vous ne pouvez aller nulle part si vous changez constamment de direction.

Réagir en permanence finit par vous faire vous sentir impuissant.

Nous lâchons le contrôle parce que nous nous sentons en sécurité.

Questions que posent les personnes proactives

#1. Questions sur les racines et les fruits

  1. Quelle est la racine de ce problème ?
  2. Quel est le fruit de ce problème ? (Que génère-t-il ?)
  3. Qu’est-ce qui vous vient à l’esprit lorsque vous vous concentrez sur les racines plutôt que sur les fruits ?

Quand le même problème continue de revenir vous importuner, c’est que vous ne résolvez que les symptômes.

#2. Questions sur la reconnaissance des schémas répétitifs

Le schéma est le problème lorsque vous continuez à devoir résoudre le même problème.

  1. Combien de fois avez-vous été confrontés à cette situation au cours des 30 derniers jours ?
  2. Quelles façons de penser/de se comporter propagent cette situation ?
  3. Que pourriez-vous essayer d’autre ?

Lorsque les mêmes problèmes reviennent sans cesse, les solutions actuelles ne fonctionnent pas.

« Si vous faites toujours ce que vous avez toujours fait, vous obtiendrez toujours ce que vous avez toujours eu. » Jessie Porter

#3. Questions sur le feu ou la fumée

Lorsque la maison est en feu, sortez immédiatement. Mais, la plupart du temps, la maison n’est pas en feu, même s’il y a beaucoup de fumée.

Si vous pouvez revenir demain matin et faire votre travail, la maison n’est pas en feu.
  1. Quel est le gain à court terme ?
  2. Quelle est la réussite à moyen terme ? Ce problème sera une victoire dans 30 jours si….
  3. Comment la solution d’hier a-t-elle causé le problème d’aujourd’hui ?

Le problème le plus difficile à voir est celui que vous avez vous-même causé.

#4. Questions à poser avant de faire quoi que ce soit

  1. Que se passe-t-il si vous continuez d’avancer sans rien changer ?
  2. Qu’est-ce qui est sous votre contrôle ? Essayer de contrôler l’incontrôlable ne conduit qu’à de la déception.
  3. Qui devrait agir maintenant ?
  4. Dans quelle mesure cette situation concerne-t-elle les personnes ?

Lorsqu’un problème concerne les personnes, tout le reste n’est que fumée.

Selon vous, comment les gens pourraient-ils être proactifs dans un monde réactif ?

Etes-vous un ingénieur QA, ingénieur QC ou testeur de logiciel ? pa Fidaa Berrjeb

Les gens pensent souvent que l’assurance qualité et le contrôle qualité sont identiques.

De plus, ils utilisent souvent l’expression Quality Assurance (QA) pour désigner les tests, mais ce n’est pas exact. Ces expressions sont liées, et il est peut être très déroutant d’essayer de clairement différencier l’assurance qualité (QA), le contrôle de la qualité (QC) et les tests et d’identifier chacune de leurs activités.

Même les gens de ce domaine s’interrogent parfois sur leur intitulé de poste : « Suis-je un testeur de logiciels, un ingénieur QA ou un ingénieur QC ? »

Dans cet article, nous définirons chaque terme et la différence entre eux, et à la fin de celui-ci, vous pourrez aisément répondre à cette question.

Avant de définir ces termes, convenons de la définition de la qualité.

D’après wikipédia :

Au sens large, la qualité est la « manière d’être », bonne ou mauvaise, d’une chose ou d’une personne. Dans le langage courant, la qualité tend à désigner ce qui rend quelque chose supérieur à la moyenne.

Le QA , le QC et les tests sont liés dans un concept plus large appelé gestion de la qualité.

La gestion de la qualité comprend toutes les activités qui dirigent et contrôlent une organisation en matière de qualité. Entre autres activités, la gestion de la qualité comprend à la fois l’assurance de la qualité et le contrôle de la qualité ISTQB CFTL.

  • L’assurance qualité englobe toutes les activités de votre stratégie visant à garantir que les exigences de qualité que vous avez planifiées seront satisfaites au fur et à mesure de la fabrication du produit. Elle intervient à chaque étape du développement logiciel, de la création du cahier des charges à la sortie du produit. L’assurance qualité est la méthode orientée processus et se concentre sur la prévention des défauts.

 

  • Le contrôle de la qualité est la phase d’inspection de l’assurance qualité. Dans le processus de développement logiciel, le QC intervient généralement à la dernière étape. Cela commence une fois qu’un produit est déjà construit. Il s’agit d’une série de procédures de test utilisées pour vérifier qu’un produit est sûr et efficace après la production de masse. C’est une méthode orientée produit qui garantit que le résultat final est le résultat attendu ou que le produit final fonctionne comme prévu.

 

  • Les tests sont un sous-ensemble du QC. C’est l’activité de détection et de résolution des problèmes techniques dans le logiciel. C’est le processus d’examen du logiciel pour détecter d’éventuelles failles. L’idée de base consiste à exécuter le programme ou le logiciel et à observer le comportement ou le résultat. Il peut fournir un niveau de confiance quant à la convivialité, les performances, la sécurité et la compatibilité du produit.

 

Expression Assurance qualité (QA) Contrôle de la qualité (QC) Test
Positionnement Sous-ensemble de SDLC Sous-ensemble de QA Sous-ensemble de QC
Orientation Processus Produit Produit
Qui ? L’équipe projet L’équipe de test L’équipe de test
Quand ? Tout au long du projet Au stade du test Au stade du test
Type de

Processus

Prévention Vérification Détection
Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées

Voici déjà le cinquième billet de Fidaa sur le domaine des tests.

(Re)Découvrez ses 4 premiers billets
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
  1. « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »
  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?
  3. Le rôle et les compétences d’un testeur dans une équipe agile
  4. Quelle est la différence entre un plan de test et une stratégie de test ?

 

Voici 4 conseils pour réduire le chaos dans votre projet.

Faire face au chaos est une chose de plus que les managers de projet se doivent de faire (et de bien faire).

Tips to Reduce Project Chaos

http://www.bonniebiafore.com/tips-to-reduce-project-chaos/ par Bonnie Biafore

Les problèmes de personnes, les pressions commerciales et la création de résultats uniques s’accompagnent de défis inattendus. Faire face au chaos est une chose de plus que les managers de projet se doivent de faire.

Voici quelques conseils pour réduire le chaos dans votre projet.

Faites des recherches sur les leçons apprises par le passé.

« Il y a des leçons à apprendre… » (relisez ce billet)

Saisir les leçons apprises est souvent comme un vœu pieux. Les gens parlent de le faire, mais s’y mettent rarement. Si c’est le cas dans votre organisation, n’abandonnez pas. Au lieu de cela, demandez aux managers de projet et aux sponsors dans votre entreprise quels problèmes ils ont rencontrés sur leurs projets. Si votre organisation dispose d’une base de données sur les leçons apprises, examinez-la attentivement. En comprenant les problèmes passés, vous pouvez élaborer des plans de risque et d’urgence avisés. Et ces plans peuvent vous aider à identifier rapidement la cause racine des problèmes potentiels et à les résoudre avant qu’ils ne créent un véritable chaos dans votre projet (et dans votre vie !)

Surveillez les changements dans le comportement de vos parties prenantes.

Généralement, lorsque les parties prenantes sont stressées, leur comportement change. Certaines pourraient devenir plus vocales, d’autres moins expressives ou exprimer des préoccupations au sujet de votre projet à l’improviste !

Ne vous contentez pas de vous demander ce qui se passe.

Amorcez des discussions en tête-à-tête avec ces intervenants pour déterminer ce qui se passe avec eux. Faire preuve de compassion pour votre partie prenante et les résultats de votre projet crée de la confiance, ce qui peut conduire à en apprendre davantage sur les problèmes potentiels. Cela mène à de meilleures idées et moins de chaos !

Évaluez les écarts par rapport à vos bases de référence et répondez-y.

À l’approche de la fin de votre projet, les écarts acceptables ont tendance à se resserrer. (relisez ce billet)

Assurez-vous de bien comprendre vos références de base pour la portée, les délais, les coûts et la qualité.

Lorsque ces mesures avoisinent des écarts de 5 %, déterminez la cause de ces variances.

Et lorsque l’écart dépasse 5 %, passez à la vitesse supérieure pour remettre les choses sur les rails et partagez le statut et vos actions avec votre sponsor de projet.

Une communication proactive sur les problèmes rencontrés et vos réponses peut inspirer confiance en votre leadership de projet, ce qui signifie moins de réunions de type « veuillez expliquer ci ou ça » et, vous l’avez deviné, moins de chaos !

Concentrez-vous sur ce qui est important par rapport à ce qui est urgent.

Si quelque chose est important et urgent, concentrez-vous d’abord sur ça !

Ensuite, travaillez sur les problèmes importants et ne vous laissez pas distraire par des choses urgentes mais sans importance comme un téléphone qui sonne et vibre.

Minimisez les distractions en éteignant votre téléphone, en mettant en pause les notifications des e-mails et en accrochant un panneau « ne pas déranger » sur votre porte.

De cette façon, vous adressez les tâches les plus vitales de votre projet. Moins de chaos !

Les projets impliqueront toujours des changements inattendus ou soudains.

Ces conseils peuvent calmer les choses pour vous et votre équipe de projet. Avez-vous des conseils à partager pour réduire le chaos dans les projets ? Si oui, n’hésitez pas à les partager en commentaires à ce billet.

Pour en savoir plus sur la réduction du chaos des projets, consultez la formation de Chris Croft Solving Common Project Problems course.

La loi de Brooks s’appliquerait-elle aussi aux financements additionnels et pas seulement aux ajouts de personnel sur les projets ?

La loi de Brooks s’appliquerait-elle aux coûts ?

https://kbondale.wordpress.com/2021/11/28/would-brooks-law-also-apply-to-cost/ par Kiron Bondale

Lorsque Fred Brooks Jr. a écrit The Mythical Man Month, il a fourni aux chefs de projet la précieuse mise en garde qui a ensuite été nommée loi de Brooks.

Ajouter des personnes à un projet en retard accroît son retard

Livre sur Amazon

Bien qu’il y ait toujours des exceptions, cette affirmation est généralement vraie.

Elle est également applicable à la plupart des types de projets, pas seulement à ceux de développement de logiciels.

Les raisons qui supportent la loi Brooks sont bien comprises, mais malheureusement oubliées par les managers de projet et les parties prenantes principales lorsque des retards surviennent.
Ajouter des personnes multiplie le nombre de relations à gérer pour les membres actuels de l’équipe.

L’acquisition et l’intégration de nouveaux membres de l’équipe distrairont ceux qui devraient se concentrer sur l’achèvement des activités critiques. Cela nécessite également plus d’efforts pour garder tout le monde bien aligné dans l’équipe et augmente les risques de conflit entre les personnes ou d’autres sources de retard interpersonnelles lorsque vous avez plus de membres dans l’équipe. Et, si la majorité des activités restantes ne sont pas basées sur l’effort, l’ajout de personnes n’aidera pas à les accélérer.

Accorder davantage de financement à un projet en dépassement budgétaire en accroitra-t-il le surcoût ?

money, money, money...Mais l’hypothèse complémentaire de l’ajout de fonds à un projet qui devrait dépasser le budget le fera-t-elle encore plus dépasser le budget ?

Tout comme la loi de Brooks qui ne s’applique pas si le projet manquait de personnel au départ, une exception serait si le projet avait un budget insuffisant au départ en raison d’une sous-estimation, d’un sous-financement ou de réserves insuffisantes pour les imprévus.

Mais lorsqu’un projet a reçu un financement suffisant pour atteindre le périmètre approuvé initialement, en quoi la résolution d’un écart de coût négatif en augmentant le budget pourrait-elle être la mauvaise chose à faire ?

Si l’écart est lié à une sous-performance, à une faible productivité ou à un coût élevé dû à une mauvaise qualité, l’ajout de fonds supplémentaires au budget pourrait encourager à continuer de faire la même chose et l’écart est susceptible d’augmenter.

jeter l'argentSi l’écart est causé par une dérive du périmètre, le fait de fournir plus de financement pourrait entraîner son utilisation comme une caisse noire par les intervenants pour obtenir des fonctionnalités supplémentaires.

Les prévisions de coûts à l’achèvement peuvent également être suspectes.

Si une hypothèse de prévision est que le rendement historique persistera, est-ce étayé par le profil de risque des activités restantes ? Si l’on s’attend à ce que les choses deviennent plus faciles, l’ajout de financement ne fera que générer des coûts d’opportunité inutiles pour l’organisation.

Les développeurs et les intervenants principaux ont généralement tendance à être plus ouverts à l’ajout de personnes qu’au financement accru de projets en difficulté, ce qui explique pourquoi cette situation est moins courante, mais lorsque c’est le cas, nous devons comprendre pourquoi l’écart de coût s’est produit et comment les prévisions à l’achèvement ont été déterminées.

Visitez le site de notre partenaire Virage Group

7 péchés des revues de projet que vous pouvez éviter !

Bien qu’il y ait probablement plus que ces 7 manières de gaspiller de précieuses revues de projet, apprenez pour commencer à reconnaitre et éviter celles-ci.

Seven Sins of Reviews

https://kbondale.wordpress.com/2021/04/18/seven-sins-of-reviews/ par Kiron Bondale

Votre équipe suit un framework Agile spécifique ou a adopté une approche mixte dans ses pratiques, un principe d’Agile est l’utilisation de courtes boucles de rétroaction pour soutenir l’inspection et l’adaptation.

Que votre équipe fixe une cadence régulière pour les évaluations externes des livrables ou qu’elles soient effectuées dans la foulée, il est important d’obtenir des retours exploitables. Mais mener une revue n’est pas seulement une question de rassembler les gens.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Bien qu’il y ait probablement plus que ces façons de gâcher les revues, en voici sept dont j’ai été témoin.

#1 – Le seul participant est un Product Owner (ou un rôle similaire représentant la voix du client).

Bien que nous nous attendions à ce que les Product Owners soient bien informés, leurs retours sont à un pas de distance de celui des véritables parties prenantes externes. Le Product Owner peut juger si le produit répond aux besoins, mais l’équipe perd l’avantage de poser des questions comme « Quelles nouvelles idées cette fonctionnalité vous donne-t-elle pour le produit ? » ou « Comment pourrions-nous faire en sorte que cette fonctionnalité ajoute plus de valeur pour vous ? ». De plus, les retours du Product Owner devraient (idéalement) être reçus par l’équipe quotidiennement plutôt que d’organiser un événement spécial uniquement à cette fin.

Visitez le site de notre partenaire Virage Group

#2 – Trop en mettre dans une seule revue et ne pas laisser suffisamment de temps aux parties prenantes pour digérer ce qu’elles ont vu.

Au fur et à mesure que les équipes s’améliorent dans la livraison, elles peuvent être en mesure d’effectuer plus de travail sur un même laps de temps.

ne chargez pas trop les revues

Dans ce cas, la fréquence des examens externes devrait être rapprochée afin que le contenu examiné soit moins important et que le contenu couvert soit organisé par ordre de priorité.

#3 – Organiser une démonstration plutôt qu’un échange bidirectionnel.

Si le seul but d’une revue est de montrer ce que l’équipe a accompli, cela pourrait être enregistré et envoyé aux parties prenantes pour qu’elles les regardent à leur guise.

La vraie valeur d’un examen réside dans la richesse des discussions entre les membres de l’équipe et les parties prenantes et entre les différentes parties prenantes en fonction de ce qu’elles voient.

L’utilisation de questions puissantes et ouvertes est un moyen de s’assurer que le partage des connaissances ne se fait pas dans une seule direction.

#4 – Avoir les mauvaises personnes dans la revue.

Il est presque aussi mauvais d’avoir les mauvais intervenants externes dans la salle que de n’en avoir aucun. Si des personas sont utilisés pour faciliter la découverte des exigences, il devrait y avoir au moins un représentant pour chaque persona si le contenu de ce qui est examiné les affecte.

Et parce qu’une revue est une séance de travail et pas seulement un forum de partage d’informations, nous ne voulons pas non plus avoir trop de monde dans la salle.

#5 – Prendre des engagements pendant la revue.

ne prenez pas d’engagements trop rapidement

Il peut être tentant pour un membre de l’équipe ou le Product Owner d’essayer de s’attirer les faveurs d’une partie prenante externe puissante en s’engageant à un changement spécifique du livrable ou sur une date de livraison, mais ce n’est pas le bon forum pour cela.

Le contenu et les dates souhaités peuvent être notés, mais le Product Owner et l’équipe doivent prendre le temps de comprendre les impacts de ces changements.

#6 – Critique ouverte du travail de l’équipe.

Il est naturel qu’une partie prenante externe soit frustrée si ses attentes n’ont pas été satisfaites pour le contenu examiné. Ces critiques sont essentielles pour aider l’équipe à s’améliorer au fil du temps.

Mais si cette critique est fournie de manière abusive, le moral et la productivité de l’équipe en prendront un coup.

#7 – Ne pas prendre suffisamment de temps pour analyser ce qui a été appris lors d’une revue.

Si nous mobilisons un temps précieux pour les parties prenantes, il nous incombe de bien utiliser leurs retours. Il peut être pratique d’organiser une rétrospective ou un artefact similaire immédiatement après une revue, mais cela peut ne pas laisser le temps nécessaire à l’équipe et au Product Owner pour digérer correctement les retours qu’ils ont reçus.

Des critiques bien managées sont un ingrédient clé de la construction du bon livrable pour nos clients, donc éviter ces sept péchés contribuera grandement à tirer une valeur réelle de ces rencontres critiques.

La métaphore du chef d’orchestre est séduisante pour le manager de projet, mais qu’en est-il dans la réalité ?

Chefs d’orchestre célèbres

https://seths.blog/2021/01/famous-conductors/ par Seth Godin

Voici une métaphore utile :

Les chefs d’orchestre célèbres sont souvent jugés sur une heure ou deux sur scène. Ils portent des vêtements coûteux, font des gestes dramatiques et reçoivent les ovations. Ils sont aussi très cher payés pour porter une très petite baguette et ils sont les seuls sur scène à ne pas produire de son.

Mais il s’avère que toutes ces choses ne sont pas ce qui fait un grand chef d’orchestre.

Ce que nous ne voyons pas :

  • Les chefs d’orchestre définissent le programme.
  • Ils ont étudié et comprennent ce qui s’est passé avant.
  • Ils travaillent à établir la culture de l’organisation.
  • Ils amplifient le travail acharné et l’esprit de corps de certains, tout en travaillant à calmer les sceptiques au sein de l’organisation.
  • Ils déterminent sur quelles voix se concentrer, et quand.
  • Ils ont moins de pouvoir qu’il n’y paraît et utilisent leur position pour diriger, pas pour manager.
  • Ils se présentent à la répétition avec un programme et une voie à suivre.
  • Ils recueillent des fonds.
  • Ils transforment beaucoup de « moi » en un seul « nous ».
  • Ils développent un point de vue. Et ils l’équilibrent avec ce dont l’auditeur, le mécène et les musiciens ont tous besoin.
  • Ils s’y attachent pendant des décennies.

C’est une forme de leadership qui se fait dans la vie privée, mais, de temps en temps, on la voit sur scène.

QRP est partenaire de DantotsuPM, visitez leur site et leur blog

La métaphore du chef d’orchestre est séduisante pour le manager de projet, mais qu’en est-il dans la réalité ?

Ce que j’ai vu sur certains projets (OK, ce n’est pas la majorité, fort heureusement, et je force beaucoup le trait 😊).

  • Les managers de projet définissent un plan qui devient obsolète dès qu’il est publié.
  • Peu connaissent bien l’organisation et les clients et donc ne comprennent pas ce qui s’est passé avant pour amener à ce projet.
  • Ils s’efforcent de gérer le moins mal possible les multiples cultures de l’organisation et de ses diverses parties prenantes.
  • Ils se concentrent sur minimiser l’impact des sceptiques au sein de l’organisation, tout en se reposant sur l’engagement de quelques-uns.
  • Ils écoutent ceux qui crient le plus fort et qui imposent leur tempo.
  • Ils n’ont absolument aucun pouvoir pour manager les membres de l’équipe projet qui pour la plupart reportent à des directions opérationnelles.
  • Ils arrivent après que le cas d’affaire ou le contrat client aient été signés sans réelle vision de la voie à suivre.
  • Ils ont zéro pouvoir sur les budgets alloués au projet.
  • Ils transforment beaucoup de « nous » en un seul « je ».
  • Ils ne développent aucun point de vue personnel. Ils se focalisent sur ce que veut le sponsor, puis en second les clients et, en tout dernier, les membres de l’équipe projet.
  • Ils ne s’attachent au projet que le temps de trouver le suivant qui servira au mieux leurs ambitions.

Et même si vous êtes effectivement un excellent « manager de projet – chef d’orchestre », un peu d’autodérision ne saurait vous nuire.

Un autre billet sur cette même thématique : Pourquoi le chef de projet est-il comme un chef d’orchestre ? par Jeff Ball

Changer de mécanisme de fonctionnement et d’exécution est coûteux.

Le coût de changer de mécanismes est plus élevé que nous lui en accordons de crédit.

Mode switching

https://seths.blog/2021/01/mode-switching/ par Seth Godin

Pourquoi trier les couverts quand vous videz le lave-vaisselle ? Pourquoi ne pas simplement mettre tout en vrac dans un tiroir et choisir ensuite les couverts dont vous avez besoin quand vous en avez besoin ? C’est la même quantité de tri, après tout.

Nous en comprenons intuitivement la raison. Si vous prenez une minute pour trier les fourchettes, couteaux et cuillères au départ, vous n’aurez pas à dépenser dix secondes à chaque fois que vous voulez trouver une fourchette.

Le coût de changer de mécanismes est plus élevé que nous lui en accordons de crédit.

Le web nous a persuadés que tout est hétéroclite, que trier soigneusement des choses et les garder où elles devraient être est une perte de temps parce que nous pouvons tout simplement les retrouver quand nous avons besoin d’elles.

Mais commuter en mode ‘recherche’ casse notre rythme et élimine la sérendipité utile qui arrive quand les bonnes choses sont placées proches l’une de l’autre, exactement là où nous nous attendons qu’elles soient.


D’où  l’importance capitale pour les managers de projets de bien classer tous les documents et les mettre à disposition des parties prenantes afin qu’elles puissent les trouver sans efforts superflus.

Ce billet publié en 2010 reste pertinent: Les bénéfices de la Documentation de Projet

Documenter le projet ? ?

Hummm…je préférerais passer ce temps sur d’autres activités plus importantes du projet.

Faisons-le après l’achèvement de toutes les activités du projet, pas tout de suite.

Je suis concentré sur la livraison du projet. La documentation peut attendre.

Je peux réaliser un projet de plus si je ne fais pas la documentation.

Cela vous est-il familier ?

Examinons quelques points clefs à propos de la documentation de projet : Pourquoi documenter ?
QRP est partenaire de DantotsuPM, visitez leur site et leur blog

Meeting après meeting après meeting après meeting après…

5 conseils pour faire face à la surcharge de réunions par Cindy Solomon

Cette réunion aurait-elle pu être un courriel ? Le phénomène de « surcharge furtive de votre agenda » où les réunions prennent peu à peu (mais totalement) le contrôle de vos journées de travail, est une perte de temps, d’énergie et de productivité.

Mais vous pouvez reprendre le contrôle !

Cindy Solomon, experte en leadership, partage ses 5 conseils pour éclaircir votre emploi du temps et reprendre le contrôle de votre agenda afin qu’il travaille pour vous, et non contre vous.

5 conseils empreints du bon sens que donne l’expérience. Pas si faciles à embrasser et cependant si puissants.

J’aime beaucoup le premier dont découle à mon sens tous les autres.