Le chapitre 5 de ce livre blanc sur le développement d’apps mobile en « Low-Code et No-Code » est spécifiquement dédié au management de ce type de projets.
Face aux mutations, les organismes gagnants ne seront pas forcément les plus forts mais vraisemblablement les plus véloces à s’adapter.
Avec un fort taux d’équipement, l’évidence de notre dépendance (addiction pour certains) vis-à-vis des smartphones et des applications mobiles, est devenu un fait bien enraciné.
Les tendances observées d’usage et de comportements des mobinautes, l’adaptation des organismes à la recherche d’agilité avec le numérique et le cloud, confirment la nécessité de créer et exploiter des applications mobiles très facilement et très rapidement.
Créer de la valeur via des applis mobiles, avec la capacité de les modifier, les faire évoluer simplement malgré un manque de compétence en développement, le contexte est donc à l’évidence propice au « No-code » « Low-Code » !
Bruno Doucende est PDG de Synertic et anime de longue date les activités du PMI en région Provence avec une belle équipe de managers de projet venus de tous horizons.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
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 ?
L’analyse SWOT (Strengths, Weaknesses, Opportunities and Threats) est une technique d’analyse fréquemment utilisée au niveau de l’entreprise, mais aussi dans les projets, dans les équipes de toutes sortes et pourquoi ne pas l’appliquer juste sur vous-même ?
Le nom SWOT est un acronyme pour les 4 dimensions de cette technique d’analyse
Strengths (Forces) : caractéristiques de votre entreprise, de votre projet ou de vous-même qui vous donnent un avantage sur les autres.
Weaknesses (Faiblesses) : caractéristiques de votre entreprise, de votre projet ou de vous-même qui vous désavantagent par rapport aux autres.
Opportunities (Opportunités) : éléments de l’environnement que votre entreprise, votre projet ou vous-même pourriez exploiter à votre avantage.
Threats (Menaces) : éléments de l’environnement qui pourraient causer des problèmes à votre entreprise, à votre projet ou à vous-même.
On parle en français de forces (ou atouts), faiblesses, opportunités et menaces.
Comme l’expose ici Christian Hohmann, il s’agit donc d’identifier les forces, les faiblesses, les opportunités et les menaces auxquelles est soumise l’entreprise dans un contexte concurrentiel. Elle peut être utilisée pour mieux positionner une nouvelle offre ou avant de lancer un projet majeur.
L’objectif de l’analyse est de miser sur vos forces bien identifiées pour transformer vos faiblesses et menaces en opportunités.
partagez ce billet avec vos amis, collègues et relations professionnelles
Négociation: Ne cherchez pas le compromis par Julien Pelabere
Livre sur Amazon
Docteur en négociation complexe (PhD) et Fondateur de l’Institut NERA – Institut de Négociation et de Recherche Appliquée (www.institut-nera.com), Julien consacre au quotidien son énergie à la formation et l’assistance des individus, des organisations et des entreprises, pour lesquels négocier et gérer les conflits est un enjeu majeur. Auteur de l’ouvrage: Négociation d’Influence, Développez votre pouvoir, Déjouez la manipulation, il enseigne également ses travaux sur la négociation et le management / leadership à l’ENA, HEC, Sciences Po Paris et Dauphine…
Écoutez bien ses 3 principes
Prenez le contrôle de vos intuitions
Passez d’une volonté de convaincre à une volonté de comprendre
J’ai récemment visionné à nouveau ces 2 vidéos de Christian Hohmann sur les enquêtes Kano que je vous propose de découvrir avant de discuter de comment utiliser ce modèle pour le management d’un portefeuille de projets.
Reprenons les bases d’une enquête Kano
Un bref rappel à propos du modèle de Kano : comprendre les trois courbes
La spécificité des enquêtes Kano : interrogation positive et négative
La table de décodage d’une enquête Kano
Exemples, cas d’usage
et, pour communiquer graphiquement les résultats d’une enquête Kano
Votre portefeuille de projets et le modèle de Kano
Si vous managez et/ou contribuez à un portefeuille de projets, vous savez que certains projets vont être capables de changer totalement les règles du jeu pour votre entreprise ou votre secteur, certains ont déjà une forte visibilité, d’autres sont plutôt exploratoires…
Pourquoi ne pas essayer de les positionner sur le modèle de Kano Noriaki ci-dessous et voir ce que vous pouvez en apprendre ?
Les attributs d’un produit/service sont les supports des attentes des clients. Ils peuvent être classés en cinq catégories :
Obligatoires, indispensables (Must-Be)
Attractifs (attirantes)
Proportionnels ou linéaires (One-Dimensional)
Indifférents
A double tranchant (Reverse)
Sur la base de cette nomenclature, quatre zones (Indifférence, basique, performance, excitant) sont repérées sur le graphe ci-dessus qui comporte deux axes :
L’axe vertical représente le niveau de satisfaction : En bas, le moins satisfait (dissatisfied), En haut, le plus satisfait (satisfied)
L’axe horizontal représente la prise en compte des attentes : À gauche faible couverture (Need not fullfilled), à droite forte couverture (Need well fullfilled) »
Après avoir complété cet exercice et positionné tous vos projets sur le graphe…
Qu’en apprenez-vous ?
Devriez-vous changer la distribution de vos investissements en fonction de cette attractivité client ?
Les fonctionnalités de certains projets devraient-elles prendre en compte leurs positionnements Kano actuels pour les faire évoluer vers davantage d’attractivité client ?
Avez-vous des projets qui répondent un peu trop à des besoins déjà largement satisfaits ? Quels seront leurs éléments différenciant ?
J’aimerais beaucoup lire vos commentaires lorsque vous aurez réalisé cet exercice sur votre portefeuille de projets !
Planisware est partenaire DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Claude Aubry exprime son premier ressenti à la lecture de la version française (qui a été depuis améliorée) et son analyse critique des différences et des apports de cette nouvelle mouture :
Ces dernières années et particulièrement depuis le lancement du manifeste Agile en 1994, un nombre incroyable et toujours croissant d’organisations et de professionnels des projets se sont tournés vers les approches Agiles dans l’objectif d’améliorer l’exécution et le retour sur investissement de leurs projets et autres initiatives de changement.
C’est une tendance qui ne se dément pas. Le dernier rapport ‘Pulse of the Profession’ du Project Management Institute indique que 53 % d’organisations placent une forte priorité sur la mise en place d’une culture réceptive aux changements.
Depuis son introduction en 2010, AgilePM s’est vite établie comme une certification majeure pour le management de projet agile.
Développée et publiée par le Agile Business Consortium, la guidance AgilePM offre une méthodologie pratique et répétable qui trouve un équilibre idéal entre les standards, la rigueur et la visibilité exigée pour la bonne gestion de projet et les rapides changements et l’auto-organisation Agile. Il offre une structure Agile structurée et évolutive dans l’entreprise basée sur une pratique prouvée.
Il y a quelques fonctions clefs d’ AgilePM qui contribuent à sa popularité et à son succès
Une approche essayée et testée en entreprise
AgilePM Certification détails
AgilePM est essentiellement un sous-ensemble pour un manager de projet du framework Agile du Agile Business Consortium. La structure, établie au fil des 20 dernières années et régulièrement revue, combine la direction et la rigueur à l’agilité et la flexibilité actuellement exigées par les organisations.
Le cycle de vie complet du projet est adressé (au-delà du développement de produit)
AgilePM offre une approche Agile mature qui, tout en offrant agilité et flexibilité, conserve les concepts d’une livraison de projet et d’un management de projet. AgilePM va au-delà des approches de développement de produit Agiles comme Scrum.
Contrôles de qualité et de gouvernance
Un des principes sous-jacents d’ AgilePM est de ne jamais compromettre la qualité. Dans AgilePM, les critères d’acceptation de projet, de haut niveau sont agréés aux diverses étapes du cycle de vie du projet, des exigences initiales à l’étape de faisabilité, des objectifs de chaque étape de développement à la livraison du produit/solution.
Management de risque
AgilePM fournit des idées pratiques pour manager le risque, adressant directement beaucoup de risques associés aux projets. Le Questionnaire d’Approche de Projet fournit un point de départ efficace pour créer une compréhension claire et partagée des risques de projet et de leur réduction.
Rôles et responsabilitésclairs
Qui va faire quoi et avec quel niveau de responsabilité et quel rôle ?
Des personnes travaillant efficacement ensemble sont la base de tout projet réussi. AgilePM le reconnaît et assigne des rôles et des responsabilités clairs à chaque personne dans un projet, représentant le business/métier, la solution/technique, le management et les processus.
Les pratiques agiles populaires sont intégrées
AgilePM incorpore et encourage une gamme de pratiques agiles populaires pour soutenir un développement de solution efficace y compris la Priorisation Moscow, le Timeboxing et le Développement Itératif.
Relisez ce billet
Une structure et une certification globales, agnostique de l’industrie
AgilePM est une approche vraiment globale avec une certification. Les candidats de plus de 80 pays se sont embarqués pour un voyage vers la certification AgilePM. Ils représentent un large panel d’organisations, d’industries et de secteurs, de petites structures de conseil à de grandes multinationales.
L’analyse des candidats démontre l’attrait d’AgilePM dans des industries diverses.
Les huit industries les plus populaires choisies par des candidats
Information et communication (15 %)
Finance et services d’assurance (13.5 %)
Administration publique et défense (7.5 %)
Autres activités de service (6.4 %)
Activités professionnelles, scientifiques et techniques (6.1 %)
Éducation (4.8 %)
Industrie (4 %)
Santé humaine et activités d’assistance sociale (2.9 %)
Les dix premiers pays pour des examens Foundation
Le Royaume-Uni (40.6 %)
La Pologne (28.3 %)
L’Australie (7.2 %)
La France (5.3 %)
Les Pays-Bas (3.0 %)
L’Afrique du Sud (2.6 %)
L’Italie (2.3 %)
La Roumanie (1.9 %)
La Belgique (1.5 %)
La Malaisie (1.1 %)
Guide sur Amazon
AgilePM Handbook est maintenant disponible en quatre langues (anglais, français, allemand et polonais), avec des examens disponibles dans sept langues (anglais, français, allemand, polonais, chinois, hollandais et italien).
Formation et certification AgilePM
Les formations accréditées pour AgilePM sont délivrées par le réseau global d’organisations de formation accréditées (ATOs) de APMG. cliquez ici pour en savoir davantage.
QRP est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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 Designde 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 :
Innovation et croissance
Réalignement organisationnel
Livraison efficace
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.
Les projets faisant la part belle à ces robots logiciels sont déjà là et la tendance va s’amplifier.
Sans être de l’IA à proprement dire, le Robotics Process Automation ou RPA peut y faire appel pour aller encore plus loin dans l’automatisation de tâches informatiques répétitives. Car c’est bien de cela dont il s’agit comme l’explique Christian Hohmann dans cette petite vidéo.
RPA fait référence à des “robots” logiciels que l’on peut programmer ou à qui l’on peut enseigner à reproduire des actions humaines telles que la saisie de données, le copier-coller, l’ouverture et la lecture de fichiers… afin qu’ils effectuent ces tâches avec des logiciels ou des applications de la même manière et à la place des utilisateurs humains.
Planisware est partenaire de DantotsuPM
En ajoutant la capacité de ces robots logiciels à apprendre au fil des réponses fournies par des humains aux traitements des exceptions (le Machine Learning), ils deviendront plus intelligents.
Le management de projets, domaine très favorable pour des projets RPA
Nombre de tâches réalisées par les chefs de projets sont à la fois répétitives, chronophages et ne nécessitent pas beaucoup d’intelligence décisionnelle.
Alors, pourquoi ne pas automatiser celles-ci avec le RPA ?
Qu’en pensez-vous ? Quelles tâches aimeriez-vous d’ores et déjà déléguer à un automate ?
La consolidation des dépenses de projets, le cumul des bénéfices dès les premiers livrables, l’archivage des feuilles de temps, la préparation du reporting hebdomadaire ou mensuel… ?
partagez ce billet avec vos amis, collègues et relations professionnelles
« 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
L’é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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Christian Hohmann partage dans cette vidéo un processus en 6 étapes, très générique, que vous pouvez utiliser pour mener une transformation ou déployer une stratégie.
Les 6 étapes cruciales pour mener une transformation sont résumées dans une infographie que Christian Hohmann commente et explique dans cette petite vidéo.
Alors, que donnent ces 6 étapes pour votre projet de transformation en 2021 ?
Remplissez ce tableau en écoutant la vidéo et apprenez à réaliser un Goal Tree.
Étapes
Vos réponses
(à remplir en écoutant les conseils de Christian Hohmann)
Quels sont votre intention stratégique, le but à atteindre, l’objectif final ?
Quels sont les prérequis, les conditions nécessaires ?
Comment décomposer en objectifs intermédiaires et bien les communiquer aux opérationnels ?
Quels sont les écarts entre la situation souhaitée et l’état actuel des choses ?
Quelle pourrait être la feuille de route pour réussir cette transformation ?
Comment allez-vous vous y prendre pour traiter cette transformation en mode projet ?
CSP est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Bonjour, de nombreuses et nombreux managers de projet et agilistes me demandent où trouver des informations sur Disciplined Agile, PMI a créé un site dédié pour partager sur cette approche d’Agilité « disciplinée ».
Bonjour, je pense que vous étiez nombreux à l’attendre et il est arrivé à la mi-novembre.
Plusieurs notables évolutions
Moins prescriptif : Scrum est ramené à un cadre minimal suffisant
Objectif de Produit, le « Pourquoi »: Chaque Sprint devrait rapprocher le produit de son objectif global.
É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.
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.
+ Lean : En effet, moins de 13 pages que je vous engage à lire et relire…
Écoutez les co-créateurs de Scrum, le Dr Jeff Sutherland et Ken Schwaber parler des mises à jour du Guide Scrum 2020 et de leur importance pour vous
AXELOS a lancé la 5ème édition de MSP®, elle met l’accent sur plus de flexibilité, d’adaptabilité et de réactivité
Managing Successful Programmes (5th Edition) sur Amazon
En effet, MSP adopte une approche incrémentale du cycle de vie du programme et permet ainsi une plus grande agilité organisationnelle.
MSP reste la prochaine étape naturelle après PRINCE2® pour développer vos connaissances et compétences pour être en mesure de répondre aux défis et de booster votre carrière. MSP fournit les connaissances et compétences nécessaires pour relever les défis auxquels vous êtes confrontés lorsque vous gérez des programmes et de multiples projets plus importants et plus stratégiques. Cette 5ème édition comprend directives, formations et certifications.
Je ne sais pas depuis combien de temps vous-même utilisez Scrum mais je pense qu’un quart de siècle de vie et d’usages est une étape importante pour cette approche et cet état d’esprit.
Que Scrum signifie-t-il pour vous ?
CertYou est partenaire de DantotsuPM
Quelques pistes pour partager votre expérience :
Quand avez-vous rencontré Scrum pour la première fois ?
Sur quel projet ?
Quel fut le résultat ?
En quoi cette approche vous a-t-elle impacté ?
Au niveau professionnel ?
Au niveau personnel ?
Aujourd’hui qu’est-ce que Scrum signifie pour vous ?
Postez vos réponses dans les commentaires: texte, vidéo, images… toutes sont les bienvenues.
Michel.
Ken Schwaber et Jeff Sutherland pour un événement virtuel en live pour célébrer leurs 25 ans (de Scrum) !
Inscrivez-vous rapidement
Le 18 Novembre: Événement gratuit (nombre de places limité)
Mê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.
partagez ce billet avec vos amis, collègues et relations professionnelles
“J’ai suivi exactement la recette et ça a échoué.”
C’est ainsi que débutent bien des commentaires sur les recettes en ligne. Puis le commentateur explique qu’il a remplacé la crème aigre par du yaourt (c’est ce qu’il avait dans le réfrigérateur), qu’il a remplacé la farine de blé par de la farine de riz (c’est sans gluten) et qu’il a utilisé le grille-pain au lieu d’un vrai four…
Une fois que vous êtes profondément investi dans un projet, c’est le vôtre. Il est en route. Vous y avez investi tout votre cœur, votre âme et votre fierté.
Face au conseil utile, il est facile de répondre: “bien sûr, c’est ce que je fais déjà”. Et de triturer ensuite votre description du projet actuel pour le faire correspondre, enfin presque, à un semblant de suivi de la nouvelle approche suggérée.
Mais ce n’est pas vrai. Vous gaspillez simplement du temps et des efforts à feindre d’utiliser cette nouvelle façon de faire de quelque chose.
Et si, pendant juste une semaine ou même un jour, vous agissiez « et si » ?
Et si vous refaisiez votre plan, ou vos perceptions du monde ou votre approche d’une façon totalement nouvelle, d’une manière qui respecte et embrasse la chose que vous avez juste apprise. Et si vous suiviez la recette en suivant la recette, simplement pour apprendre cette technique…
Après avoir appris à maîtriser parfaitement une technique, vous pourrez peut-être commencer à la modifier selon vos besoins.
Après cela, après que vous ayez vu ce qu’elle peut faire, allez ensuite de l’avant et voyez ce qui arrive quand vous refaites la chose qui vous avait amenée à chercher une nouvelle recette en premier lieu.
Dans une ère d’accès illimité à des recettes, la partie difficile sur obtenir un bon conseil n’est pas de l’obtenir. C’est de le suivre. Et ensuite, vous pourriez être capables d’intégrer la recette et d’en faire une réelle compréhension.
Je profite de ce billet pour vous rappeler que depuis peu PMI® a mis en ligne le « Resource Hub ».
Le Project Management Institute® a rassemblé une variété de ressources en ligne gratuites, d’événements virtuels et même un avant-goût de nouvelles offres numériques pour aider les managers de projets à se connecter à une communauté mondiale, à acquérir des compétences et à se préparer à progresser dans un monde que nous espérons prochainement « post-COVID-19 ».
Visitez le PMI Covid-19 Resource Hub
Explorez et partagez ces ressources, et revenez souvent car il y a de fréquentes mises à jour.
Relisez l’article de Jean-Baptiste Jourdant : cultivez vos talents – Projet et qualité, de nombreux points communs !
Les équipes et des organisations s’efforcent constamment de trouver les meilleures façons de travailler. Bien des organisations doivent faire plus avec moins, moins de personnes ou moins d’argent. Et les organisations veulent toujours trouver des façons d’économiser de l’argent, de gagner en efficacité et rendre l’environnement de travail meilleur. Mais souvent la demande par la gestion pour faire ainsi peut sembler accablante.
Mais si vous saviez qu’il existe une approche structurée pour essayer des améliorations possibles, obtenir des retours rapidement et le faire d’une façon qui vous permette d’apprendre dans un environnement contrôlé et de construire sur vos succès, vous seriez probablement intéressés, non ?
Et bien cette approche existe ! Et c’est quelque chose que vous pouvez facilement apprendre et enseigner à votre entourage.
Faites un pas de plus et donnez-lui une chance. Et si vous trouvez une façon d’économiser à votre société de l’argent ou du temps, vous pourriez bien en obtenir un agréable bonus!
Plan Do Check Act – Cycle PDCA
Le Plan Do Check Act – Cycle PDCA est une méthode en 4 étapes utilisée dans le processus d’amélioration continue.
Le livre de Deming sur Amazon
PDCA est aussi connu sous le nom de Cycle de Deming. Dans les années 1920, Walter Shewhart a créé le concept Plan – Do – See (Planifier – Faire – Observer) connu comme le Cycle Shewhart. Edwards Deming l’a ensuite adapté. Une autre variation que vous pouvez rencontrer est le Cycle PDSA : Plan-Do-Study-Act, Planifier-Faire-Etudier-Agir
Mais ils mènent tous à la même chose…
Toutes ces approches s’est concentré sur l’amélioration continue. Et chacun des quatre composants joue un rôle spécifique dans ce processus d’amélioration continue.
Le Plan Do Check Act – Cycle PDCA est une méthode à 4 étapes fréquemment utilisée dans le processus d’amélioration continue. Chacun des quatre composants joue un rôle spécifique dans ce processus d’amélioration continue.
Plan – Préparer, Planifier
Relisez ce billet: Diagramme D’Ishikawa (Fishbone) pour aller chercher la source des problèmes.
En déterminant comment réaliser des améliorations, il est important de comprendre le problème. Vous ne pouvez pas mettre en œuvre des activités d’amélioration si vous ne comprenez pas d’abord le problème. Vous devez comprendre la cause première, dite cause racine, ses impacts et toute autre information appropriée sur le problème.
C’est ce que vous faites pendant cette phase de préparation.
Une fois que vous avez une meilleure compréhension du problème, vous développez alors un plan pour développer des améliorations.
Pour obtenir une approche plus normative de ces activités, les étapes 1 à 5 du papier 7 Problem-Solving approach peuvent vous être utiles. Elles vous montrent pas à pas comment vous assurer que vous avez une pleine compréhension de la situation, définissez le problème correctement et choisissez la meilleure solution pour la situation. Vous développerez alors un plan pour développer la solution.
Une partie de la planification est comprendre votre ligne de base de départ et savoir quelle métrique utiliser pour mesurer vos progrès. C’est la seule façon pour vous de savoir si vous avez fait des améliorations adéquates.
Avant de passer à l’exécution de votre plan, identifiez clairement à quoi ressemblera le succès et comment vous saurez si votre approche était réussie. Vous devez être capables d’identifier des résultats quantitatifs ou qualitatifs pour savoir si vous avez été gagnants.
Do – Développer, réaliser, mettre en œuvre
Jusqu’ici, vous et votre équipe avez acquis une bonne compréhension du problème et vous avez développé un plan pour l’adresser.
Vous savez quelles sont vos bases de départ et ce que signifie la réussite.
Maintenant vous exécutez votre plan. Vous pouvez le faire de deux manières différentes.
Vous pouvez mettre en œuvre votre plan sur un pilote, testant les réalisations avec un petit groupe avant de dérouler le plan pour tous.
Ou vous pouvez exécuter votre plan avec un plus grand groupe, mais vous assurer que le test est contrôlé.
Que vous choisissiez l’une ou l’autre de ces approches, mettez en œuvre les activités que vous avez identifiées pour atteindre des améliorations.
Check – Contrôler, vérifier
Après un délai prédéterminé, mesurez les résultats des changements effectués. Validez si les changements atteignent vos attentes.
Vérifiez par rapport aux mesures de vos lignes de base du départ. Utilisez la métrique que vous avez identifiée avant le lancement.
Vous voulez voir si votre plan a fonctionné et si vous avez obtenu des résultats positifs.
Vous identifierez aussi où vous pouvez encore améliorer le plan. Vous pouvez devoir tordre certaines choses ou modifier le plan en vous vasant sur ce que vous avez appris.
Vérifiez des résultats par rapport à votre ligne de base et voyez si votre plan a marché comme prévu. Vous pouvez vous devoir l’adapter. C’est un cycle apprenant.
Act (ou Adjust) – Agir, ajuster, réagir
Maintenant que vous savez si vos actions ont apporté une amélioration ou pas, exécutez les étapes suivantes appropriées.
Amélioration continue…
Si vous avez mis en œuvre votre amélioration sur un petit groupe pilote avec des résultats positifs, vous pouvez être prêts à lancer les changements sur un plus grand groupe.
Si vous avez exécuté ces changements sur le plus grand environnement et que tout est bon, vous standardiserez alors les changements pour qu’ils deviennent les nouveaux normaux dans l’environnement.
Alternativement, si les changements réalisés n’ont pas fourni les résultats attendus, ajustez le plan.
Et même si vous avez obtenu des améliorations, vous pouvez trouver en avançant que de nouvelles améliorations sont nécessaires. Dans ce cas vous pouvez répéter le cycle.
C’est l’objectif de l’amélioration continue.
Repeat – Répéter
Le Cycle PDCA n’est pas une activité isolée. Les équipes exécutent le cycle à plusieurs reprises pour continuer à améliorer les processus et construire sur des améliorations précédentes.
Votre équipe et environnement se sont améliorés, mais il y a probablement toujours une marge d’amélioration à exploiter.
De nouvelles connaissances, technologies ou approches peuvent survenir qui pourront aider l’équipe à performer encore mieux.
Ou votre nouvelle ligne de base peut vous donner une compréhension sur la façon de s’améliorer encore de différentes façons.
Ou vous pouvez être si inspirés que vous voulez essayer le cycle PDCA sur un autre processus de votre environnement.
Vous n’êtes pas limités sur combien de fois vous pouvez utiliser le cycle PDCA pour continuer à vous améliorer.
Les bénéfices du Cycle PDCA
Il y a de multiples bénéfices au Cycle PDCA :
Boucle de retours continue
PDCA vous donne une grande boucle de retours du terrain pour apprendre rapidement si votre plan fonctionne ou si vous deviez essayer une approche différente.
Perturbation limitée des processus business.
Vous pouvez essayer des solutions potentielles d’abord à une petite échelle avec un groupe pilote. Cela vous permet d’en apprendre davantage sans perturber l’organisation toute entière.
Gagner l’implication d’autres personnes.
Il faut souvent que beaucoup de membres de votre équipe s’engagent et participent dans la résolution de problèmes. S’ils contribuent à travailler vers des améliorations, cela peut les inspirer et les aider à voir le lieu de travail sous un nouveau jour. Ils peuvent même commencer à contribuer davantage à la résolution de problèmes et à l’amélioration continue.
Créer une culture d’amélioration continue.
Vous pouvez créer une culture d’amélioration continue et construire continuellement sur des succès.
Soyez conscients de ces défis
Ce cycle si simple a de super pouvoirs.
Quand vous utilisez le cycle PDCA, il y a plusieurs considérations à prendre en compte :
Il faut du temps. Le Cycle PDCA n’est pas une approche qui peut être utilisée sur des problèmes qui doivent être résolus rapidement.
Il faut de la discipline. Pour effectuer le cycle de ces activités, vous devez comprendre votre ligne de base, ce que signifie réussir et comment vous mesurerez ce succès.
Il faut un environnement contrôlé. Pour savoir si ce sont bien vos activités qui ont apporté le succès, vous devez être capables de contrôler l’environnement en effectuant votre pilote. Sinon, cela pourrait être simplement une corrélation d’autres événements et pas la cause de la réussite. Si c’est le cas, déployer ces changements à l’organisation toute entière pourrait ne pas avoir les résultats positifs vous attendez.
En bref
Vous voici prêts avec votre organisation à aller décrocher une étoile.
Le Cycle PDCA ne saurait être une réparation rapide, mais sa structure est facile à comprendre et à communiquer. Il peut être utilisé dans beaucoup de situations différentes et vous permettre de créer une véritable culture d’amélioration continue.
Et une fois que vous l’avez utilisé pour faire des changements réussis dans un secteur, vous chercherez probablement autre part où l’appliquer pour encore plus d’améliorations !
partagez ce billet avec vos amis, collègues et relations professionnelles
Rares sont les projets sans aucune technologie. Avec l’explosion des smartphones, des réseaux sociaux, et plus récemment l’accélération du travail à distance, nombreux sont les projets de nouveaux produits et services qui portent des aspects technologiques qui manquent pour les entreprises. Hors, il faut encore très souvent passer par la DSI pour développer son nouveau projet d’application, de place de marché ou autre… Submergés par les demandes, ce sont autant d’opportunités pour les DSI en surchauffe de se réinventer…
Il n’y a tout simplement pas assez de temps pour tous les nouveaux projets…
Il est en effet difficile d’avoir tous les bons profils au bon moment pour gérer l’ensemble des nouvelles demandes de projets. Et, une fois les projets exécutés, cela ajoute à la charge de maintenance de ces mêmes DSI.
Hexagon est partenaire de DantotsuPM
Et si les chatbots pouvaient aider à désengorger ce flux de projets ?
Depuis quelques années, de nombreux projets pensent aux solutions basées sur des chatbots. En effet, c’est une interface utilisateur intéressante. Elle permet, grâce à l’intelligence artificielle (ou le machine learning) de comprendre les intentions des utilisateurs et d’y répondre automatiquement, voire de les anticiper. De plus, les chatbots présentent ceci avec une interface graphique standardisée, ce qui facilite les développements et l’adoption par les utilisateurs.
Pour l’entreprise, il faut alors décider qui va les réaliser, les maintenir et comment gérer toute la phase d’apprentissage. Entre les efforts liés au déploiement sur la technologie cible choisie (Teams, Hangouts, Facebook, Google Home etc.), le choix de la meilleure solution technologique (DialogFlow, Luis, Watson, Snips ?), la connexion au SI de l’entreprise, il n’est pas si facile de développer un chatbot utile, qui crée réellement de la valeur et sera en conséquence fortement utilisé !
Les pré-requis pour réussir son projet de chatbot, car ce n’est pas si simple un chatbot
1. Bien s’équiper et distinguer ce qui est « core business » de ce qui ne l’est pas. En général, la partie Compréhension du Langage Naturel ne l’est pas. Il existe d’excellents algorithmes « sur étagère » qui permettent de développer ses cas d’usage. Donc, choisir et prioriser.
2. Déterminer quel sera le canal de communication ou bien les canaux si l’on choisit d’en avoir plusieurs. Attention, à chaque nouveau canal, ce seront des efforts de développement et des délais additionnels qu’il faudra prendre en compte.
3. Penser l’amélioration continue dès le départ. Quand le cas d’usage entrera en production, comment construire le reporting et comment l’améliorer ?
De la techno mais pas que
Les outils et choix technologiques sont bien sûr une partie importante de ces projets mais la complexité des projets de chatbot ne se limite pas à l’outillage.
Il faut aussi penser parcours utilisateurs, canaux de communications, mesures d’efficacité, d’adoption et d’usages, maintenance de la solution et évolutivité.
Êtes-vous en tant que leader et manager de projet, en train de créer un environnement résistant à la volatilité et aux incertitudes (VUCA/VICA) ?
VICA est un acronyme de Volatilité, Incertitude, Complexité et Ambiguïté. Tous ces facteurs peuvent affecter votre business, équipe ou environnement. Mais il y a certainement quelque chose que vous pouvez entreprendre pour y faire face et, de même, apprendre à vos gens à le manager.
Analysons brièvement comment on peut approcher un environnement VUCA :
VOLATILITÉ
Le changement peut survenir en un claquement de doigts.
PROBLÈME : Le changement arrive brusquement, de façon incontrôlable et non de manière prévisible. Il peut déstabiliser et mener à de mauvaises décisions si l’organisation n’a pas de compréhension détaillée de l’environnement.
SOLUTION : Une vision motivante donne aux gens une image plus claire de la situation. C’est fondamental pour permettre une réaction rapide aux changements.
INCERTITUDE
Le futur est souvent imprévisible.
PROBLÈME : L’avenir est presque imprévisible et ne tient pas compte d’un plan détaillé. Vous ne pouvez tout simplement pas tenir compte de toutes les variables possibles.
SOLUTION : Étudiez « le champ de bataille ». Plus vous connaissez le business/environnement, mieux vous pouvez faire face aux menaces ou profiter d’opportunités.
COMPLEXITÉ
Il y a tellement de variables à prendre en compte.
PROBLÈME : Les marchés et l’environnement, en général, sont chaotiques parce qu’ils consistent en trop de variables.
SOLUTION : Les objectifs et tâches doivent être clairs pour chacun. Apprenez aux gens à travailler ensemble et à résoudre des problèmes complexes; les compartiments étanches mèneront à l’échec.
AMBIGUÏTÉ
Diagramme D’Ishikawa (Fishbone) pour aller chercher la source des problèmes.
PROBLÈME : Il n’y a aucune clarté et il est difficile de trouver la cause première des problèmes.
SOLUTION : Encouragez la créativité et l’agilité. Favorisez une culture d’amélioration continue et d’apprentissage; les gens habiles et pleins de ressources peuvent facilement découvrir des menaces émergentes.
J’en ai repris l’illustration en français car je pense qu’elle peut nous être utile.
Utile pour considérer les événements, risques et opportunités sur nos projets sous le prisme Volatilité, Incertitude, Complexité et Ambigüité.
Sur l’axe des abscisses, horizontal, nous prenons en compte notre connaissance de la situation avec l’ensemble des facteurs qui peuvent l’impacter. Donc en élargissant notre vue à l’écosystème dans lequel notre nouveau projet vient s’insérer par exemple.
Sur l’axe des ordonnées, vertical, nous examinons avec honnêteté notre capacité à anticiper le résultat de nos actions.
Ainsi un événement survenant quand nous en savons peu sur la situation et ne savons prédire le résultat de nos actions génère de l’ambigüité.
Si nous connaissons bien le présent et comprenons bien l’impact de nos actions, le risque majeur peut être la fréquence des changements, donc la volatilité…
Partenaire de DantotsuPM
N’hésitez pas à partager vos propres idées et réflexions sur cette représentation bi-dimensionnelle de VUCA.
partagez ce billet avec vos amis, collègues et relations professionnelles
Bruno Doucende est PDG de Synertic et anime de longue date les activités du PMI en région Provence avec une belle équipe de managers de projet venus de tous horizons.
Une partie de la planification est comprendre votre ligne de base de départ et savoir quelle métrique utiliser pour mesurer vos progrès. C’est la seule façon pour vous de savoir si vous avez fait des améliorations adéquates.
DantotsuPM.com 