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.

Quand vous estimez les ressources et délais pour un projet, quelle méthode choisir ?

Les estimations imprécises ou incorrectes dans les projets est l’une des raisons principales d’échec.

Estimating Resources for a Project: What Method to Choose?

https://www.actitime.com/project-management/project-estimation/

« Image courtesy of Stuart Miles / FreeDigitalPhotos.net »

Les estimations imprécises ou incorrectes dans les projets est l’une des raisons principales d’échec. Leurs conséquences vont d’échéances manquées à une totale incapacité de livrer le projet. C’est pourquoi une analyse prudente du temps disponible, du budget et des compétences des ressources nécessaires exige une attention toute spéciale.

Il y a quelque temps, nous avons publié un article sur comment l’évaluation de projet fonctionnait au temps de la préhistoire (pour faire court : essentiellement comme maintenant). Mais plaisanteries mises à part, l’estimation des ressources est une partie essentielle de la planification de projet. C’est un prérequis pour correctement planifier le travail à faire, le distribuer, obtenir un échéancier et un budget approuvés et bien plus.

Comme il existe diverses techniques pour l’estimation  des ressources, il n’est pas toujours évident de savoir laquelle fonctionnerait le mieux pour votre projet spécifique.

Dans cet article, nous jetons un coup d’œil aux techniques les plus communes et voyons où et quand elles peuvent être utilisées.

a.  Jugement d’expert

Cette approche d’évaluation implique l’utilisation de l’expertise de spécialistes expérimentés. Parfois, elle exige la collecte et l’analyse de données adéquates, le rôle de l’expert étant l’interprétation du résultat. Parfois, elle est basée sur l’avis du spécialiste. Les experts qui sont engagés dans un processus d’évaluation basé sur cette méthode ne devraient pas nécessairement appartenir à l’équipe projet : des spécialistes externes sont souvent recrutés.

Le jugement lui-même (que ce soit juste un avis ou une interprétation de l’analyse de données) représente d’habitude la somme des expériences précédentes de l’expert et inclut sa connaissance théorique de toute méthode spécifique, de données et observations obtenues par la pratique et d’un jeu de critères.

  • Pour : La capacité à prendre des facteurs uniques en considération; la capacité à utiliser des avis externes et l’expertise de spécialistes expérimentés.
  • Contre : Cette approche a tendance à utiliser des avis personnels et donc le résultat est soumis aux biais des humains.
  • Quand et où utiliser : Dans les projets complexes où l’évaluation qualitative n’est pas suffisante et ceux qui ressemblent de manière significative à une expérience précédente.

b.  Évaluation comparative, par analogie

L’évaluation par analogie est basée sur la comparaison des progrès et résultats de projets semblables précédemment exécutés pour évaluer les ressources nécessaires sur le prochain. Les résultats positifs comme négatifs sont pris en compte. Si le projet avait été un succès, il peut être utilisé comme modèle pour estimer et planifier le nouveau projet. Si c’était un échec, l’expérience acquise peut être utilisée pour les ajustements nécessaires dans l’estimation des ressources, l’anticipation des risques, la prévention de potentiels problèmes, le management du contenu et périmètre du projet, etc.

  • Pour : Une des façons les plus rapides d’estimer les ressources.
  • Contre : Faible exactitude; risque élevé de conclusions erronées.
  • Quand et où utiliser : Cette méthode marche le mieux pour des projets typiques avec une portée de travail similaire. Elle est souvent utilisée dans les premières étapes d’un projet pour obtenir une évaluation de haut niveau de combien de ressources seraient nécessaires.

c.   Évaluation de haut en bas (top-down)

On appelle souvent cela la « vue d’hélicoptère » car on voit bien tout le périmètre du projet mais on est trop haut pour bien voir tous les détails.

La méthode d’estimation de ressource top-down est basée sur la décomposition du travail de projet en blocs de travail de haut niveau, puis estimer ceux-ci et cumuler ces évaluations. Plus tard, les gros blocs de travail de haut niveau peuvent être décomposés en plus petites parties dès que des exigences plus détaillées sont disponibles et peuvent être estimées séparément. Cette méthode d’estimation est souvent utilisée dans les projets Agiles où les résultats rapides sont primordiaux.

  • Pour : Une façon rapide d’estimer les ressources et d’évaluer la viabilité du projet.
  • Contre : Faible exactitude; la quantité de ressources nécessaires peut varier significativement de l’évaluation de départ.
  • Quand et où utiliser : Cette méthode fonctionne au mieux dans les étapes initiales d’un projet quand une estimation grossière et rapide est exigée.

d.  Évaluation de bas en haut (bottom-up)

À la différence de la technique précédente, l’évaluation bottom-up utilise les estimations de toutes les petites tâches incluses dans le périmètre du projet. Cumulées, ces estimations fournissent la pleine image de combien de ressources le projet va consommer. Logiquement, elle est utilisée à un moment où tous les détails nécessaires sur les tâches détaillées du projet sont disponibles.

  • Pour : Forte exactitude du résultat, écart relativement faible entre les ressources estimées et réellement consommées.
  • Contre : Un niveau élevé de détail et de temps sont nécessaires pour mettre en œuvre cette technique.
  • Quand et où utiliser : Cette méthode est utilisée au moment où tous les détails de la décomposition du projet en tâches sont disponibles. Elle fournit une image relativement précise des ressources nécessaires pour achever un projet.

e.    Évaluation selon un modèle paramétrique

faire la somme des dépensesL’évaluation par modélisation paramétrique utilise des variables pour calculer des estimations pour de futurs projets. Dans cette méthode, des variables mesurables sont utilisées pour prédire et estimer le travail à venir. Cette technique est plus scientifique que la plupart des autres approches, car elle permet de compter sur ses données comme une base précise pour planifier les tâches de projet.

  • Pour : La méthode assure une exactitude maximale de l’estimation résultante.
  • Contre : La complexe collecte de données est et leur traitement sont des parties indispensables pour utiliser cette méthode.
  • Quand et où utiliser : On considère cette méthode comme universellement applicable, mais elle marche bien surtout dans des domaines où des paramètres de projet peuvent être calculés à l’avance (la construction, l’architecture etc.) et où des données précises sont cruciales dans les premières étapes.

f.      Évaluation à 3 points

Cette méthode d’estimation provient de PERT (Program Evaluation and Review Technique) et utilise trois estimations pour calculer l’estimation finale : optimiste, très probable et pessimiste. Le résultat est calculé selon une moyenne pondérée de ces trois évaluations originales.

  • Pour : La méthode permet de tenir compte d’estimations et d’avis de participants variés, elle permet une automatisation et peut fournir rapidement des résultats.
  • Contre : Des quantités significatives de données et de granularité de détails sont exigées.
  • Quand et où utiliser : La méthode est utilisée dans les projets où la planification est basée sur PERT et dans des projets où l’incertitude est réduite en utilisant des évaluations à trois points comme technique de management du risque.
Bien plus qu’un outil de gestion de projet
Découvrir l’ERP de gestion de projet

Résumé

Le choix de la bonne méthode d’estimation dépend des spécificités du projet, des pratiques générales dans la société ou dans l’équipe, du domaine dans lequel le projet est exécuté et bien d’autres facteurs.

Ces simples indications sur les diverses méthodes d’estimation sont destinées à vous donner rapidement une vue d’ensemble de ce qui pourrait ou pas fonctionner pour votre projet spécifique et vous donner un aperçu de comment et où elles marchent le mieux.

billets les plus lus en Décembre 2020 sur DantotsuPM.com : Chemin Critique, Meilleures conversations et nouveau guide Scrum

Des sujets variés ont été les plus lus ce mois de Novembre: Techniques avec Critical Path et le nouveau Guide Scrum, ou bien leadership avec l’amélioration des conversations pour les leaders.

4 idées fausses sur le Chemin Critique (Critical Path)

La plupart des personnes non-techniques ne savent pas ce qu’est le chemin critique. Celles travaillant sur des projets informatiques savent ce que cela signifie à un haut niveau, mais ont une faible compréhension de sa réelle mécanique et comment elle peut rapidement changer le résultat de leurs projets !

La vérité est qu’il y a beaucoup d’idées fausses sur chemin critique. Démystifions certaines des principales.

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

Le guide Scrum 2020 est paru le 18 Novembre

  1. Guide téléchargeable gratuitement

    Moins prescriptif : Scrum est ramené à un cadre minimal suffisant

  2. Objectif de Produit, le « Pourquoi »: Chaque Sprint devrait rapprocher le produit de son objectif global.
  3. Élimination des comportements « proxy » : Une seule équipe Scrum concentrée sur un même objectif de produit avec 3 différents jeux de responsabilités : Product Owner, Scrum Master et développeurs.
  4. Engagements et auto-gestion : Pour le Product Backlog, il s’agit de l’Objectif de Produit, le Sprint Backlog a un Objectif de Sprint et l’Increment a une Definition of Done. La version 2020 met l’accent sur une Scrum Team autogérée qui choisit qui, comment et sur quoi travailler.
  5. + Lean : En effet, moins de 13 pages que je vous engage à lire et relire…
CertYou est partenaire de DantotsuPM

10 façons d’avoir de meilleures conversations pour un(e) leader

Quel message vos paroles envoient-elles, chers leaders ? Améliorez vos compétences de communication chaque jour avec ces « petites » astuces.

CSP est partenaire de DantotsuPM

 

4 idées fausses sur le Chemin Critique (Critical Path)

Il y a beaucoup d’idées erronées sur chemin critique, démystifions certaines des plus courantes.

Four Misconceptions about the Critical Path

https://www.mpug.com/articles/four-misconceptions-about-the-critical-path/ par Ronald Smith

La plupart des personnes non-techniques ne savent pas ce qu’est le chemin critique. Celles travaillant sur des projets informatiques savent ce que cela signifie à un haut niveau, mais ont une faible compréhension de sa réelle mécanique et comment elle peut rapidement changer le résultat de leurs projets !

La vérité est qu’il y a beaucoup d’idées fausses sur chemin critique. Démystifions certaines des principales.

1ère Idée fausse

« Le chemin critique est le plus court chemin pour traverser le le planning du projet (l’échéancier) »

Réalité : Le chemin critique est le chemin le plus long du diagramme de réseau. C’est la séquence des activités qui collectivement définissent les dates de début et de fin pour le projet et dans laquelle aucune tâche n’a de surplus, de marge de temps inutilisé. A l’inverse, des chemins non-critiques ont des marges disponibles qui sont le temps pendant lequel une tâche peut glisser. Vous pouvez avoir un peu de retard sur cette tâche sans décaler celles qui la suivent ni impacter la date d’achèvement du projet.


2ème Idée fausse

« Chaque tâche sur le chemin critique est critique. »

Réalité: Le mot « critique » dans ce contexte n’indique pas combien ces tâches ont d’importance au projet complet, mais se réfère plutôt à comment leur planification affectera la date de fin du projet. Aussi, les gens doivent-ils se souvenir qu’après qu’une tâche sur le chemin critique soit achevée, elle n’est plus « critique » puisqu’elle ne peut plus affecter la date de fin de l’échéancier.


3ème Idée fausse

« Le chemin critique ne changera jamais. »

Réalité: Chaque projet a au moins quelques changements (par exemple, le périmètre, les délais, et-ou l’argent) qui signifie que le chemin critique changera. Cela aboutira à une nouvelle date d’achèvement attendue pour le projet. D’autres raisons pour lesquelles le chemin critique changera parfois est quand certaines des tâches seront achevées en avance ou en retard par rapport au planning, et/ou des relations entre des tâches peuvent changer.


4ème Idée fausse

« Si vous raccourcissez la longueur d’une tâche qui se trouve sur le chemin critique, le projet sera achevé plus tôt. »

Réalité: Ça dépend ! Si cela se produit, il est plus que probable que la tâche « raccourcie » sur le chemin critique soit alors remplacée par une tâche plus longue et non-critique qui devient maintenant une tâche du chemin critique. Cela signifie que vous avez un nouveau chemin critique et une nouvelle date d’achèvement.

Il est important de vous rappeler que réduire le chemin critique sur la plupart des projets afin de raccourcir la durée d’un projet n’est pas un exercice insignifiant. Il peut au contraire être ardu et générer d’autres problèmes. Par exemple, vous pourriez accroître vos risques projet et devoir refaire certaines choses. Bien sûr, il y a des façons et techniques qui peuvent probablement raccourcir la durée d’un projet pour respecter une nouvelle contrainte de temps si cela est réalisé correctement. Par exemple, la portée du projet pourrait être réduite et/ou vous pourriez avoir plus de personnes assignées pour travailler sur des tâches critiques ce qui aiderait à compresser le planning.

La théorie des contraintes avec Christian Hohmann

Dans cette introduction à la théorie des contraintes, Christian Hohmann répond à quelques questions que l’on se pose sur celle-ci.

  • Livre sur Amazon

    Qu’est-ce que la théorie des contraintes ?

  • Qu’est-ce qu’une ressource « goulot » ? Comment l’identifier ?
  • En quoi la théorie des contraintes va-t-elle nous servir ?
  • Quelles ont les étapes de mise en œuvre de cette théorie ?
  • Quel positionnement par rapport à Lean (revoyez ce billet et vidéo:
    Muri, mura et muda, les familles de gaspillages selon Lean par Christian Hohmann ) et Six Sigma ?

Quelques règles et une devise à comprendre !


chemin critiqueMême si la théorie vient du monde manufacturing, on voit facilement qu’elle s’applique très bien au monde du management de projet. En effet, il est très fréquent d’avoir à utiliser des ressources rares et onéreuses dans les projets : Expert, machine ou équipement, utilisateur, développeur pointu sur une technologie… Ce sont souvent celles-ci dont l’utilisation doit être la plus optimisée possible car elle peuvent ralentir la progression de tout le projet si indisponibles quand on en a besoin sur le chemin critique.