L’attrait de #NoEstimates

Quand bien même plus de 50% de la portée de votre projet aurait été livrée, êtes-vous systématiquement en mesure de fournir une estimation précise de la date de fin du projet ?

The allure of #NoEstimates

https://kbondale.wordpress.com/2021/03/28/the-allure-of-noestimates/ par  Kiron Bondale

Un manager de projet m’a récemment posé une question que l’on m’a souvent posée au cours de ma carrière.

« Comment dois-je me conduire avec un intervenant qui, lorsque je fournis une estimation approximative de l’ordre de grandeur au début de la vie du projet, insiste jusqu’au bout pour me tenir responsable de la limite inférieure de cette fourchette, même lorsque suffisamment de preuves ont émergé pour contredire cette estimation initiale ? »

La question indique clairement qu’une fourchette de valeurs a été fournie et qu’aucun engagement n’a été pris. Et pourtant, le comportement de la partie prenante est le même que si une estimation fixe et ferme avait été donnée.

Les biais d’ancrage et de confirmation peuvent expliquer en partie pourquoi cela se produit, mais cela fournit peu d’aide au manager de projet à qui l’on demande de fournir une estimation au tout début d’un projet.

Et, même si plus de 50% de la portée du projet a été livrée, nous pourrions ne toujours pas être en mesure de fournir une estimation précise.

Nous apprenons qu’une façon simple de calculer l’estimation à l’achèvement d’un projet est de la baser sur les performances passées, mais est-ce souvent le cas dans la réalité ? Pour fournir une prévision précise, nous aurions besoin d’un processus de livraison qui soit sous contrôle, et pourtant, la plupart du temps, nous ne pouvons avoir qu’une influence limitée sur les facteurs qui pourraient provoquer l’échec d’un modèle prédictif.

Regarder uniquement en arrière donne rarement une bonne vision de l’avenir.

Si nous n’avons pas une disponibilité fiable des personnes, quelle que soit l’approche de livraison que nous utilisons, nous ne serons pas en mesure de prédire quand nous aurons terminé tant que tout le contenu n’aura pas été livré. Des métriques telles que la vélocité, le débit ou l’âge moyen des items de travail sont aussi utiles qu’une boule magique dans de telles conditions.

Il n’est pas impossible de s’assurer que tout le monde soit disponible en cas de besoin, mais c’est difficile à réaliser lorsque des engagements de livraison sont pris sans tenir compte de la capacité de l’organisation à livrer.

Même avec un personnel dédié, à moins que le niveau d’incertitude associé au travail restant soit inférieur ou égal à ce que l’équipe a connu jusqu’à présent, l’histoire passée ne prédit pas la performance future. Le management des risques aide en encourageant une équipe à manager les menaces de gravité élevée le plus tôt possible, mais cela suppose qu’elle est en mesure d’identifier les menaces clés. Plus un projet est complexe, plus il est difficile de le faire. Tout ce qu’il faut pour invalider une estimation de niveau de confiance élevé, est la matérialisation d’un unknown-unknown (un risque totalement inconnu et imprévisible) particulièrement méchant. Les réserves de contingence et de management permettent une certaine absorption des chocs, mais sur des projets extrêmement complexes, la liste des mauvais résultats est bien longue.

Un porte-conteneurs s’est retrouvé coincé sur le côté dans le canal de Suez il y a peu. Ce n’est pas la première fois qu’un tel problème de navigation se produit, mais quatre jours plus tard, personne n’était en mesure de fournir une estimation précise de la rapidité avec laquelle le canal serait débloqué.

Si vous managez un projet qui ne ressemble à aucun autre, pourquoi vous attendriez-vous à être en mesure de mieux prévoir quand vous aurez terminé ?

#NoEstimates peut ne pas être acceptable pour de nombreux intervenants, mais c’est peut-être la réponse la plus responsable dans certaines circonstances.

Les projets en questions par Jean-Yves MOINE

Les questions élémentaires sont la base de la gestion de projet, savoir comment elles s’articulent permet de prendre en compte le projet dans toutes ses dimensions, et de mieux comprendre de quoi on parle.

Je m’étais amusé par le passé à réaliser une analyse fonctionnelle de la gestion de projet. C’est-à-dire à décrire les besoins de la gestion de projet. J’avais constaté qu’ils tournaient tous autour des questions élémentaires, dans l’ordre : Pourquoi ? Quoi ? Comment ? Où ? Qui ? Quand ? Combien ? Pour quoi ?

Imaginez une base de données qui pourrait répondre à toutes les questions élémentaire combinées que l’on pourrait se poser

Qui fait quoi ? Combien coûtent les équipements ? Quel est le périmètre du projet ? Quel est le processus pour réaliser un Produit ? etc.

Ce serait évidemment très utile pour le chef de projet. C’est même tout ce dont il a besoin.

Je suis consultant en gestion de projet, et développeur aussi, pour les projets. Quand j’interviens chez un client, je pose toujours les mêmes questions, des questions simples : Qu’est-ce que vous faîtes ? Comment vous le faîtes ? et Où vont les produits que vous réalisez ?

Cela me permet de bâtir le WBS du projet qui intègre les localisations puisque le planning (le quand ?) n’est autre que l’expression du WBS dans le temps dans la méthode que j’applique.

Viennent ensuite les questions élémentaires : Qui réalise les tâches ? et combien coûtent t’elles ? Je bâtis ainsi une base de données qui met en relation toutes les réponses conformément au synoptique suivant :

Les questions simples impliquent des réponses simples

Je m’attends à ce que l’on me donne une information précise et concise. Les détails tuent en effet l’information lors des interviews, ils font perdre du temps.

La standardisation sur les projets permet de capitaliser, on peut noter qu’elle correspond aux questions : Quoi ? Comment ? et Qui ?

A noter qu’un plan est la combinaisons des questions : Quoi ? comment ? Où ? Qui ? Quand ? Combien ? C’est la définition.

On peut se poser la question : Pourquoi fait-on le projet ? C’est pour obtenir un retour sur investissement. Et peut se poser la question : Pour quoi fait on le projet ? C’est l’ouvrage final.

En appliquant cette méthode, on obtient une vision complète du projet assez rapidement. Un projet bien structuré peut être ensuite bien géré, le but est de tenir les objectifs QCD (Qualité, Coût, Délais).


Sur Amazon

Jean-Yves Moine chez PlaniSolutions est consultant en gestion de projet depuis plus de 25 ans.

Il a exercé pour de grands groupes industriels sur des projets allant de la fabrication de boîtes de vitesses, au terminal méthanier ou aux tramways, en France et à l’international.

Il a également écrit plusieurs livres sur la gestion de projets, dont 4 parus chez AFNOR éditions.

À propos de prédire le futur

On demande souvent au manager de projet, non seulement de prédire l’avenir, mais aussi de prévoir tout ce qui pourrait l’empêcher de se matérialiser et d’y remédier par anticipation !

On predicting the future

https://seths.blog/2020/04/on-predicting-the-future par Seth Godin

2 choses

  1. Nous le faisons tout le temps. Constamment.
  2. Nous y sommes épouvantables.

Nous passons nos jours à essayer de deviner comment une action impactera l’avenir et nous nous trompons souvent.

Et nous passons le reste de nos journées à espérer que nos prédictions étaient justes ou à nous inquiéter qu’elles ne le soient pas. Nous essayons de contrôler l’avenir à mesures égales par la psychokinésie et l’inquiétude.

Quand l’avenir ne coopère pas, nous passons encore plus de temps à essayer de changer la particule de futur suivante pour qu’il finisse par correspondre de plus près à l’avenir que nous espérions.

Et si, au lieu de cela, juste pour petit moment, nous faisions simplement de notre mieux ?

Et laissions l’avenir prendre soin de lui-même.

Parce que même si nous ne nous en préoccupons pas, l’avenir prendra toujours soin de lui-même.

Tout ce qui nous incombe est de donner notre meilleur en prêtant attention à la communauté et aux gens que nous servons.

Bien plus qu’un outil de gestion de projet
Découvrir l’ERP de gestion de projet

Résilience

Le monde va changer et la résilience est notre meilleure réponse.

https://seths.blog/2021/03/resilience-3 par Seth Godin

Il ne s’agit pas de construire des choses qui tourneront toujours de la manière à laquelle nous nous attendons. Les solutions à toutes épreuves sont trop chères, trop rigides et exigent une connaissance parfaite de l’avenir.

La résilience est un engagement sur une conception, une attitude et un système qui travaille même quand les choses ne vont pas de la façon dont nous les avions projetées. Particulièrement dans ce cas-là.

Au lieu de concevoir pour le meilleur scénario, nous faisons l’effort de considérer comment notre travail va s’épanouir quand le meilleur cas ne se produit pas. Parce que c’est beaucoup plus probable.

Les marins savent que fixer d’un point sur l’horizon est une bonne façon de survivre à une tempête.

La résilience, la communauté et le sens des possibilités peuvent mener loin. Cela ne rend pas les choses plus faciles, mais c’est notre meilleur chemin pour avancer.


C’est souvent dans les moments les plus difficiles, quand le projet ou la vie nous met à l’épreuve, quand nous nous sommes fourvoyés ou mis dans des situations impossibles que la résilience de certains fait merveille.

Bien plus qu’un outil de gestion de projet
Découvrir l’ERP de gestion de projet

En voici un témoignage surprenant et qui donne aussi à réfléchir sur notre propre attitude et capacités peut-être encore insoupçonnées à rebondir.

Priorisation des tâches : Maintenant, Ensuite, Plus tard, Jamais (améliorons le MoSCoW)

Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.

Now, Next, Later, Never (improving MoSCoW)

https://watirmelon.blog/2019/10/14/now-next-later-never-improving-moscow/ par Alister Scott

Notre équipe se donne des objectifs trimestriels, que nous décomposons en exigences dans des sprints bimensuels. En tant que paradev (un paradev iest quiconque dans une équipe de développement ne fait pas que programmer) dans mon équipe, je travaille étroitement avec notre Product Owner pour écrire et déterminer la priorité de ces exigences.

Nous avons à l’origine commencé par utiliser la méthode de MoSCoW  pour déterminer la priorité de nos exigences : Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.

Méthode MoSCoW sur Wikipedia

Nous avons rapidement commencé à remarquer que la terminologie (Must have, Should have, Could have, et Won’t have) ne marchait pas idéalement dans notre contexte et nous pensions que cela causait beaucoup de frictions sur comment nous donnions la priorité et la communiquions à l’équipe. Il ne semblait pas naturel de classifier des choses comme, Must, Should, Could, Won’t car non corrélées à ce sur quoi nous devrions (Should) travailler.

En quelques sessions nous avons inventé nos propres groupements pour nos exigences en nous basant sur quand nous voudrions les voir dans notre produit : Maintenant, Ensuite, Plus tard, Jamais. Nous avons continué à utiliser ces quatre termes et nous avons constaté qu’ils ont été très bien adoptés par l’équipe car il est très naturel pour nous de penser avec ces groupements.

Le plus grand avantage à utiliser Maintenant, Ensuite, Plus tard, et Jamais, est qu’ils se transfèrent naturellement dans notre plan de produit et dans la planification de sprint.

J’ai fait quelques recherches en écrivant ce billet et j’ai trouvé Maintenant, Ensuite, Plus tard comme une approche de ThoughtWorks datant de 2012, mais je n’ai pas trouvé de lien qui contienne Jamais que nous avons trouvé très utile pour lister ce que nous reconnaissons que nous ne ferons pas.

Comment abordez-vous l’établissement de la priorité de vos exigences ?

Bien plus qu’un outil de gestion de projet
Découvrir l’ERP de gestion de projet

Que faire quand vous « héritez » d’un nouveau projet ?

Quand vous reprenez un projet en cours et que vous devez vous mettre à niveau et en mouvement rapidement, il peut être difficile de savoir par où et quoi commencer.

What to Do When You Get a New Project

https://www.sarahmhoban.com/blog/what-to-do-when-you-get-a-new-project par Sarah Hoban

Par où commencer ?

J’ai récemment hérité de 3 nouveaux projets oui, trois : d’un collègue qui partait pour une autre opportunité. Quand vous héritez de quelque chose en cours et que vous devez vous mettre à niveau et en mouvement rapidement, il peut être difficile de savoir ce que vous devriez faire en premier.

  • Qu’est-ce qui vaut la peine d’être appris (et fait) immédiatement ?
  • Qu’est-ce qui peut attendre ?

Voici plusieurs choses que les managers de projets devraient considérer en prenant les rênes d’un nouveau projet

#1 – Apprenez à connaître vos parties prenantes.

Le management de projet est surtout le management des personnes. Aussi, la première chose que je recommanderais de faire en héritant d’un nouveau projet est de comprendre ce qui se passe avec les gens. Qui est le/la sponsor de projet ? Qu’aime-t-il/elle et n’aime-t-il/elle pas ? Quel est son style préféré de travail? Lesquelles des parties prenantes présentent le plus de challenges ? Quelles approches le/la manager de projet actuellement en place utilise-t-il/elle pour communiquer avec ces parties prenantes ? Une fois que vous commencez à sentir le client, cherchez ensuite à comprendre l’équipe. Qui fait le travail ? Quelles sont leurs forces et faiblesses ? Quelle sera leur disponibilité à l’avenir ? Vous pouvez toujours lire la documentation de projet plus tard, mais si vous avez une heure avec le/la manager de projet actuel pendant la transition, il vaut mieux utiliser ce temps pour rassembler autant d’intangibles que possible.

CSP est partenaire de DantotsuPM

#2 – Identifiez les prochaines immédiates étapes.

Une fois que le/la manager de projet a pris le temps de vous donner l’état des lieux sur les parties prenantes, assurez-vous qu’il/elle vous envoie une copie du rapport d’avancement le plus récent et vous fasse part des actions suivantes que vous devez mener. Si vous n’avez pas encore passé en revue les documents du projet, ses conseils sur que faire et ne pas faire n’auront pas beaucoup de sens tout de suite, mais cela viendra. Notez autant de détails que vous pouvez en recueillir de ce qui est à faire et pour quand. Vous vous remercierez vous-même de cela plus tard.

#3 – Rencontrez votre équipe.

Une fois que vous avez discuté avec le/la manager de projet et identifiez les actions en cours, prenez du temps pour vous présenter à l’équipe, de préférence en personne et si possible en tête-à-tête. Cette conversation initiale devrait se concentrer sur apprendre à vous connaître l’un l’autre en tant que personnes. Parlez boutique au minimum, si vous le pouvez.

Un ordre du jour pour cette réunion pourrait inclure :

    • Contexte / intérêts personnels
    • Style de travail préféré
    • Aspirations de carrière et comment cela traduit dans leur rôle préféré sur ce projet
    • Idées d’amélioration (J’utilise cette occasion pour répéter qu’ils sont les experts, pas moi, et que je m’attends à ce qu’ils/elles me disent si un certain aspect du projet pourrait être mieux traité. Je constate que je reçois beaucoup de suggestions quand je fais cette demande. La personne ne craint pas de m’offenser puisque je suis étrangère au processus actuel.)

#4 – Analysez le budget.

Une fois que vous avez une compréhension de votre client et de votre équipe, faites-vous votre propre idée des chiffres. Si le client aime avoir à disposition beaucoup d’experts coûteux, mais n’aime pas dépenser son argent, c’est une conversation à avoir au plus tôt. Et vous ne souhaitez pas l’avoir avant d’être familier des contraintes du projet. Travailler sur les chiffres vous aide à valider l’état actuel des données financières et vous confirme sur votre plan de dotation en personnel pour le reste de l’engagement.

#5 – Familiarisez-vous avec les documents contractuels.

Passez en revue la portée du projet et toutes les exigences contractuelles et évaluez le respect de ces exigences. Si quelque chose n’est pas livré, pourquoi pas ? Cela importe-t-il ? Si cela importe et ce n’est pas là, créez un plan de remédiation et examinez-le à la loupe avec votre sponsor ou autre superviseur. Parlez avec d’autres personnes pour chercher conseils quand nécessaire et assurez-vous que vous tenez les gens informés des risques potentiels que vous percevez pour qu’ils ne se développent pas en quelque chose de plus substantiel à adresser.

#6 – Établissez un échéancier.

Une fois que vous avez passé en revue la portée / le périmètre, préparez un échéancier de projet pour l’engagement en entier (en utilisant des dates des livrables, si fournies.). Posez les lignes de base du planning, le statut de quand les choses ont été achevées dans la réalité pour mettre en évidence les différences entre les estimations et les données réelles. Utilisez ces données factuelles en plus des données de dotation en personnel pour créer un échéancier pour le reste du projet. (Tant que je n’ai pas cela dans Microsoft Project, je ne peux pas dormir la nuit. Mais cela peut juste être moi 🙂 )

#7 – Appelez le client.

Une fois que vous avez repris les rênes de l’ancien/ne manager de projet, demandez-lui d’envoyer un email au client pour vous présenter (vous ne devriez pas devoir faire cette demande, mais on ne sait jamais). Répondez-y en exprimant votre enthousiasme pour le travail et demandez à en discuter dans quelques jours pour vous donner l’occasion de monter en connaissance. Prévoyez 2-3 jours pour vous donner le temps d’achever les étapes 1 à 6. Vous obtiendrez des informations sur le client, rencontrerez votre équipe, digèrerez les chiffres, passerez en revue les aspects légaux et rédigerez votre plan d’attaque. Au moment où vous parlez avec les clients, vous serez mieux placé pour adresser n’importe quelles grenades complémentaires qu’ils pourraient jeter dans votre direction.

Planisware est partenaire de DantotsuPM

#8 – Infusez de la créativité dans les modes de fonctionnement actuels.

Engagez-vous confidentiellement à faire 1 ou 2 choses différemment de votre prédécesseur. Prenez en compte des suggestions de l’équipe pour améliorer un processus interne. Demandez au client des réactions sur le/la manager de projet précédent/e afin d’évaluer la bonne santé du relationnel en place. Puis, trouvez d’autres domaines dans lesquels l’équipe peut fournir du support. Comme vous cultivez le relationnel avec le client, vous serez capable de valider ces idées initiales en matière de faisabilité et ferez des suggestions d’amélioration, comme il se doit.

Bien plus qu’un outil de gestion de projet
Découvrir l’ERP de gestion de projet

 

Ouvrage Collectif – « Le management de projet par le FLUX » par Anthony Fouqué et Grégoire Conesa

Le 4ème thème de l’ouvrage collectif est « Établir une gouvernance solide, gérer habilement les dimensions technique et politique »

Le livre « Innover, Organiser, Inspirer pour réussir sa Transformation » Techniques et témoignages de vie de Chefs de Projet de la Francophonie sera publié très prochainement.

Cet ouvrage collectif nous invite à suivre le parcours original et personnel de professionnel(le)s auteurs chacun d’un chapitre et qui nous y livrent les leçons tirées de leur expérience dans le management de projet et le leadership.


« Le management de projet par le FLUX »

Anthony Fouqué et Grégoire Conesa présentent une vraie étude de cas d’une petite société qui conçoit et fabrique des systèmes luminaires et qui a réussi, suite à un appel d’offre, à multiplier par 20 le nombre de produits mis sur le marché.

Pour ce faire, elle a utilisé conjointement  les approches Agile, Lean Engineering et Chaîne Critique. En tant que consultant pour la société, Anthony a aidé Grégoire, le responsable du bureau d’étude de l’entreprise, à relever en six mois le grand défi technique et humain qu’un tel changement d’échelle représente.

Véritable binôme lors de cette implémentation, ils ont pu combiner les avantages du regard et de l’expertise externe avec les capacités d’exécution internes. Ils ont ensemble identifié les problèmes principaux car «il n’est pas pertinent de discuter de la solution si nous ne partageons pas le même constat sur les problèmes ».

Cet exposé mêle des éléments théoriques (Project Schedule Network Diagram, chemin critique, chaîne critique, management visuel, « fever chart », pipeline management) mais expliqués de manière très pédagogique et avec une présentation de bout en bout de la mise en place d’un management par le flux.

Vous suivrez j’en suis sûr, ce retour d’expérience avec grande curiosité, comme la résolution d’une vraie intrigue policière.

D’autant plus que les résultats furent au rendez-vous
  • Deux semaines après l’application de ces principes, mise sur le marché de l’équivalent de 6 produits soit autant que pendant les 12 mois précédents !
  • 2 mois plus tard, 40 produits étaient à disposition pour les nouveaux marchés…

Ne manquez pas le témoignage d’Anthony Fouqué lors du prochain wébinaire du PMI France Région Globale.

Vendredi 12 – « Le management de projet par le FLUX » & « Organisation humaine des structures PMO pour grands programmes internationaux »

CSP est partenaire de DantotsuPM

MSP 5ème édition : qu’est-ce qui change ?

La 5ème édition de Managing Successful Programmes (MSP ®) a maintenant été officiellement lancée.

MSP 5th edition – what has changed?

https://www.axelos.com/news/blogs/november-2020/msp-5th-edition-what-has-changed par John Edmonds

Si vous êtes familiers des versions précédentes de MSP, particulièrement celle publiée en 2011, vous vous demandez probablement en quoi cette nouvelle version diffère des précédentes.

Les concepts fondamentaux de la version précédente (principes, thèmes et processus) forment toujours la structure de base du guide et il y a quelques éléments de l’édition 2011 qui sont aussi plus clairement adressés dans la 5ème édition.

  • Vision : Le but et les caractéristiques d’une bonne formulation de vision
  • Bénéfices : Restent un principe MSP et fil conducteur dans tout le guide
  • Risques : Sont traités de façon semblable et sont adressés dans plusieurs, plutôt qu’un unique endroit
  • Plan : Maintenant renommé target operating model avec davantage d’explications sur son utilisation.

Ces quatre éléments clefs (vision, bénéfices, risques et target operating model) sont maintenant tous décrits dans le thème Design de la nouvelle édition de MSP et soulignent de cette façon la nature intégrée d’un programme.

CSP est partenaire de DantotsuPM

D’autres secteurs majeurs de la 4ème édition sont toujours présents dans la nouvelle édition

  • La structure d’organisation et les rôles
  • Cas d’affaires.
  • Engagement des parties prenantes et la planification des communications sont revisités et mis à jour.
  • Le programme lifecycle (Cycle de vie du programme), précédemment appelé le Flux Transformationnel, est revu et la nature progressive d’un programme est soulignée. La livraison progressive des bénéfices est intégrée dans chaque processus.

La structure complète de principes, des thèmes et le programme lifecycle forme toujours la colonne vertébrale de MSP.

Les principes MSP

Details for Managing Successful Programmes (MSP®)

Les principes ont été récrits pour assurer qu’ils sont valables dans l’environnement actuel. Les principes expriment tous ce que cela signifie de mener un programme en utilisant MSP et mettent en exergue les secteurs les plus critiques au succès de programme.

On explique chaque principe dans un paragraphe relativement court, avec une description de comment ce principe est appliqué dans chaque thème MSP.

Les thèmes MSP

Il y a maintenant 7 thèmes plutôt que les neuf de l’édition précédente et ils sont maintenant appelés des Thèmes plutôt que des Thèmes de Gouvernance. Les thèmes sont présentés avec une discussion sur les gouvernances de programme et d’entreprise et les relations entre elles. La stratégie de programme et des plans de programme viennent ensuite.

Chaque chapitre exprime les rapports avec les principes MSP, les rôles clefs et les responsabilités et les informations principales dont on a besoin pour supporter le thème. Cela signifie que chaque thème donne des conseils très pratiques pour le lecteur.

Le cycle de vie du Programme MSP

Petit à petit, les livrables du programme cumulent des bénéfices.

Les programmes sont conçus pour obtenir des bénéfices pour les parties prenantes pendant tout le cycle de vie du programme. Comme de nouvelles informations deviennent disponibles, des ajustements doivent être opérés. Le management de programme exige un focus sur l’étude et le design pour ré-imaginer la progression vers l’état futur souhaité.

Le ‘Flux Transformationnel’ de l’édition précédente a été rebaptisé programme lifecycle et inclut maintenant sept processus. Ceux-ci incluent Identifie le programme (pour donner un début contrôlé au programme) et Ferme le programme (la fin contrôlée). Les processus intermédiaires forment un cycle de vie cyclique.

Chaque processus dans le cycle de vie est d’abord décrit avec son but, ses objectifs et son contexte. Puis les données d’entrée du processus, les activités dans le processus et les productions en sortie du processus.

Enfin, chaque chapitre de processus explique comment les thèmes sont appliqués à ce processus et commente sur les responsabilités des rôles clef de MSP dans ce processus.

Scénarios

Dans chacun des sept chapitres de thème, il y a quatre scénarios fictifs qui illustrent comment MSP peut être utilisé selon les raisons du programme.

Ces raisons ou fils conducteurs sont :

  1. Innovation et croissance
  2. Réalignement organisationnel
  3. Livraison efficace
  4. Livraison efficiente
Guide sur Amazon

En résumé, l’essence de ce qu’est un programme reste la même : Il est temporaire, il est centré sur les bénéfices des livrables et il s’agit de faire avancer de multiples projets et d’autres travaux.

MSP a été un grand guide et une inspiration dans la pratique de mener des changements complexes au fil des ans et la 5ème édition continue à intégrer l’avancée des réflexions sur des contrôles essentiels et des pratiques adaptables pour le management de programme.

Le nouveau guide est disponible

Biais Cognitif – L’illusion de planification

L’illusion de planification est un phénomène dans lequel la personne qui estime combien de temps sera nécessaire pour achever une tâche future fait preuve d’un optimisme qui influence et sous-estime le temps réellement nécessaire.

problèmesBien que la personne ait connaissance que des tâches passées de nature semblables ont pris plus longtemps que cette nouvelle estimation. Ce bais cognitif impacte la personne estimant ses propres tâches à réaliser alors que des personnes extérieures démontreront des estimations pessimistes, surestimant le temps nécessaire.

En quoi sommes-nous concernés dans nos projets ?

Comme Daniel Kahneman l’a si justement expliqué, cette tendance peut nous amener à sous-estimer le temps nécessaire, les dépenses et les risques et en même temps à surestimer les bénéfices des mêmes tâches. L’erreur de planification aboutit alors non seulement à des dépassements de temps, mais aussi des dépassements de coûts et des bénéfices irréalisables.

Comment éviter le plus possible ce travers ?

Multipliez les méthodes d’évaluations et élargissez le cercle des contributeurs à ces évaluations. Voir ce billet sur les techniques et approches d’évaluation (Top-down, bottom-up, expert, paramétrique…). Ajoutez une très large marge d’erreur si êtes obligé d’aller trop vite pour avoir le temps de valider sereinement les estimations (faites du fois 2 ou fois 3 par rapport au premier chiffrage).

Il existe de nombreuses techniques d’estimation qui permettent de fiabiliser vos prédictions.

Ce biais peut-il nous être utile ?

En combinant les estimations trop optimistes des « sachants » et trop pessimistes des « novices » sur la tâche à accomplir, vous pouvez arriver à une estimation relativement fiable (méthode PERT dite en 3 points) et en relativement peu de temps.

FDF est partenaire de DantotsuPM

Biais Cognitif – Biais d’optimisme

Nous surestimons souvent les chances de nos propres succès comparés à d’autres personnes.

Le biais d’optimisme, également connu sous le nom d’optimisme comparatif est un biais cognitif qui amène une personne à croire qu’elle est moins exposée à un événement négatif que d’autres personnes. Quand nous entreprenons personnellement quelque chose, nous nous attendons plutôt à des événements positifs qu’à des événements négatifs. De plus, Le biais d’optimisme se manifeste à propos d’événements positifs (comme penser avoir une meilleure capacité à manager les risques que toute autre personne) ainsi que d’événements négatifs (comme croire qu’il est moins probable que son projet soit dé-priorisé par le management).

En quoi sommes-nous concernés dans nos projets ?

Les experts techniques qui vont estimer la difficulté et durée de tâches complexes auront involontairement tendance à surestimer la capacité de l’équipe à réaliser ce qu’ils proposent. Voyant clairement ce qui est accomplir, ils s’attendent naturellement à des événements positifs : Le reste de l’équipe sera capable de réaliser ce qu’ils envisagent, les problèmes seront facilement surmontables, les ressources seront à 100% disponibles pour travailler sur cette tâche prioritaire…

Comment éviter le plus possible ce travers ?

Jouez l’avocat du diable

Quand le portrait dressé par un membre de l’équipe semble idyllique ou « trop beau pour être vrai » ou un peu trivial, il y a de fortes chances pour que le biais d’optimisme soit à l’œuvre. Le chef de projet n’est pas le rabat-joie de service mais doit souvent jouer « l’avocat du diable » pour bien valider les hypothèses prises par le membre de l’équipe qui semble trop optimiste. Quand les hypothèses de départ seront connues et examinées, des risques vont souvent apparaitre qui pourront, ou pas, être gérables dans le contexte et les contraintes du projet.

  1. Si vos experts pensent que le taux d’adoption spontanée de la nouvelle application sera 90%, assumez 60 % et mettez en place des actions d’accompagnement musclées.
  2. Si vos meilleurs développeurs estiment que le travail peut être réalisé en 8 jours, prévoyez-en 12 car tous les développeurs qui contribueront ne sont peut-être pas à leur niveau.
  3. Si le confinement et le télétravail diminuent un peu la productivité, prévoyez qu’il durera longtemps et révisez vos durées de projets.
  4. Si votre plan suppose la disponibilité de ressources à 100%. Ne soyez pas sur-optimiste sur leur capacité d’exécution. Certaines prendront des congés, des formations ou seront appelées sur d’autres tâches. D’autres pourraient se consumer rapidement à vouloir trop en faire non-stop pour votre projet.
FDF est partenaire de DantotsuPM

Ce biais peut-il nous être utile ?

Billet et vidéo à (re)voir

Les événements positifs entraînent souvent des sentiments de bien-être et d’estime de soi. Un optimisme règne alors qui est favorable à la motivation de l’équipe, à la satisfaction du sponsor et des parties prenantes. Sans avoir systématiquement recours à la méthode Coué, il faut savoir qu’elle fait souvent ses preuves et que votre optimisme de manager de projet sur les chances de succès du projet influe sur la motivation de l’équipe et par là-même apporte un surcroit d’énergie très bénéfique au projet. Votre optimisme est contagieux !

Un plan conservateur qui réussit est bien meilleur qu’un sur-optimiste : Pensez avec optimisme, planifiez avec pessimisme et exécutez avec intransigeance.