Un diagramme de Gantt permet le suivi des délais d’un projet et sa représentation sous la forme d’un diagramme.
En l’absence d’un logiciel de gestion de projet, le tableur Excel pourra réaliser ce diagramme en utilisant astucieusement un graphique en barres empilées.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Beaucoup de personnes demandent si le PMI lancera un Corpus des connaissances Agile PMI. La réponse est « Non ». D’une part, il serait presque impossible de se mettre d’accord sur ce qui y entrerait, particulièrement en considérant le désaccord sur ce qui constitue une déclaration officielle sur les structures Agile elles-mêmes (par exemple. Scrum, XP, Kanban). D’autre part, nombreux sont ceux qui pensent qu’un standard officiel Agile serait trop restrictif et irait même à l’encontre de l’intention « adaptative et itérative » du mouvement Agile. Cependant, un Corpus des connaissances Agile PMI n’est pas la seule façon d’avancer. À la place, il y a deux projets passionnants en voie de réalisation qui promettent une nouvelle avancée des techniques Agiles dans la communauté PMI.
D’abord, la 5ème Édition du Guide PMBOK est en revue publique. Pour la première fois dans l’histoire du PMBOK, les termes « le développement progressif itératif » et « Agile » sont explicitement définis.
Deuxièmement, PMI collabore avec l’IEEE pour développer « l’Extension Logicielle au Guide de PMBOK » (the « Software Extension to the PMBOK Guide »). Comme pour les extensions aux domaines de la Construction et des organisations Gouvernementales réalisées auparavant, l’Extension Logicielle fournira des outils et des techniques pour implémenter le Guide de PMBOK dans un environnement spécifique au développement logiciel. Étant donné qu’Agile est devenu une approche dominante pour les projets logiciels, ce document donnera des détails sur les approches « itératives-incrémentales » et « Agiles » brièvement mentionnées dans le nouveau Guide PMBOK. Aussi, vers le troisième trimestre de cette année, PMI vous donnera l’occasion de soumettre votre propre retour d’information sur ce document. Pour plus d’informations, vous pouvez lire un billet de blog de Mike Griffiths qui est membre de ce comité: http://leadinganswers.typepad.com/leading_answers/2011/09/the-new-software-extension-to-the-pmbok-guide.html
Bien qu’il n’y aura pas de Corpus des connaissances Agile PMI officiel dans un avenir proche, ces deux projets fourniront beaucoup de valeur à ceux qui les attendent avec impatience.
Et n’oubliez pas que Agile tient davantage de la philosophie que de la méthode et peut donc être appliquée à bien d’autres domaines que le développement logiciel. Dans cette vidéo, Joe Justice applique les principes Agile qu’il a embrassés dans le développement logiciel à la construction automobile et crée ainsi une nouvelle voiture à la fois performante et efficiente en un temps record.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Alors que Project Conférence 2012 a débuté hier à Phoenix, Arizona, voici pour ceux qui n’auraient pas la chance d’y être une vidéo enregistrée lors de Tech Ed 2012 à Paris.
Cette session de 50 minutes était consacrée à la gestion de portefeuille avec Microsoft Project Server 2010. Elle fut animée par Nathalie Hesters (chef de produit Project et Visio chez Microsoft France) et Vincent Capitaine de Campana & Schott Cabinet de conseil leader dans la gestion de projet et l’optimisation de processus.
N’hésitez pas à consulter cette vidéo si vous souhaitez tout savoir sur les réponses apportées par Microsoft pour vous permettre un management optimisé du portefeuille des projets de votre entreprise.
Comment Microsoft Project Server 2010 permet-il d’identifier et de sélectionner les projets qui apporteront le plus de valeur à votre entreprise, en fonction de la stratégie définie, en tenant compte des contraintes budgétaires et des ressources ?
Les organisations sont sous l’emprise du changement, de l’augmentation de la pression compétitive des marchés et des défis dans le secteur public qui toutes continuent à exiger une plus grande efficacité. Dans certaines organisations où tous les gains en efficacité ont déjà été exploités, le besoin domine d’un changement transformationnel et de faire les choses de façon radicalement différente.
De tels niveaux de changement peuvent apporter le potentiel de largement bénéficier de ces opportunités, mais pour beaucoup ils peuvent apporter chaos et inefficacité quand la délivrance de services est distraite par l’adoption de changements non justifiés et un management réactif.
Managing Successful Programmes est essentiellement une structure pour implémenter le changement. Toute personne qui lit le livre découvrira rapidement les différences significatives par rapport au management de projet. Le focus est sur l’engagement et le management de l’environnement dans lequel le projet fonctionne en réagissant aux opportunités et des défis plutôt qu’en s’isolant, en résistant au changement et en se concentrant sur la livraison en interne.
Il y a de nombreux bénéfices à adopter MSP, nous utilisons le mot « adopter » intentionnellement, parce que dans la plupart des organisations les éléments de la structure MSP existent déjà, donc elle n’est pas implémenté en tant que telle, elle aide à saisir la signification de ce qui est déjà là et permet d’identifier les écarts et obstacles auxquels s’attaquer.
Pour ceux qui envisagent d’adopter la structure MSP, voici les cinq avantages principaux que vous apprécierez :
1. Une structure de gouvernance améliorée et cohérente : Cela aborde les questions de faire le lien avec la stratégie business, le changement organisationnel et la livraison de projet. En établissant les jeux clairs de rôles et responsabilités qui couvrent non seulement les projets et la structure de contrôle pour le Manager de Programme, mais aussi en s’assurant qu’il y ait une propriété et responsabilité claire de délivrer le changement par le rôle de managers du changement dans le business (« Business Change Managers »). La responsabilité de tout le programme est intégrée dans un unique rôle, le Propriétaire Responsable Senior (Senior Responsible Owner : SRO). Cette structure permet un contrôle hiérarchique efficace de la direction, par le cadre responsable qui s’assure que les besoins business primordiaux restent sous son contrôle stratégique pendant la conception et la livraison tout en suivant le rythme des changements.
2. Acquérir l’agilité de réagir au changement parce qu’un besoin critique pour tout programme est d’être clair sur l’état actuel (« as is ») de l’organisation et celui « désiré » (« to be ») à atteindre. Avoir cette clarté permet des évaluations rapides de l’impact de changements de circonstances et un réalignement sur les nouveaux besoins de l’organisation. Quand il y a un certain nombre de programmes en cours d’exécution, les évaluations d’impact peuvent également être prises à travers tout le portefeuille avec efficacité. Rendre les organisations agiles accroit leur avantage concurrentiel en des temps turbulents comme ceux que nous vivons actuellement, ce qui contribue à l’augmentation du taux d’adoption de MSP ™.
Partenaire de DantotsuPM
3. Amélioration de l’alignement stratégique et clarté de direction sont des besoins fondamentaux de chaque approche de programme. Dans un Programme MSP ™ cet alignement est réalisé à travers deux concepts principaux : le Plan, qui est une description détaillée de ce que le Programme laissera derrière lui une fois achevé et les bénéfices détaillés et comment ils seront réalisés, par qui et comment ils seront mesurés. Sans le Plan pour focaliser les projets sur leurs livrables et les descriptions des bénéfices profil pour expliquer comment leurs livrables seront utilisés, les programmes trouveront très difficile de définir les priorités et pourront rapidement perdre la direction et le focus. Un problème commun dont beaucoup d’entre vous le sont conscients.
4. Se concentrer sur les bénéfices à délivrer efficacement le changement business est un avantage critique une fois que MSP ™ a été adopté. Le focus des programmes passe de la coordination de projets à la préparation, la livraison et la mise en place du changement qui permet de délivrer des bénéfices durables. Une caractéristique des organisations ayant intégré le management de programme est qu’elles font moins de projets, mais réalisent plus de bénéfices parce que leurs efforts sont concentrés sur faire des choses importantes.
5. Une fondation pour l’amélioration de la performance de l’organisation comme le prouvent les mises en place réussies de structure de management de programme à travers le monde. Il y a une industrie accréditée par l’ OGC[1] qui fournit des qualifications, des formateurs, des conseils et des outils pour supporter l’adoption et le développement des capacités des organisations. L’outil le plus important pour cela, du point de vue MSP ™ est P3M3 ™[2], qui fournit un modèle de maturité qui peut être utilisé par les organisations pour cibler leurs investissements et maximiser les bénéfices à court et long termes de l’adoption de MSP.
Pour conclure, comme le dit le vieil adage : « Personne n’a jamais été mis à la porte pour avoir choisi IBM » et de plus en plus cette même phrase s’applique à la sélection des structures de bonnes pratiques de l’OGC, dont MSP ™ est un élément clé. Son approche flexible avec un focus sur faire le lien entre la stratégie et le changement par la délivrance efficace de projet fournit une structure qui permet aux organisations de piloter efficacement le changement.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici une très esthétique présentation de l’évolution de Microsoft Project qui met en exergue quelques unes des évolutions fondamentales de la version 2010 !
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Jean-Yves Moine, consultant en gestion de projet depuis plus de 15 ans, a exercé pour de grands groupes industriels sur des projets allant de la fabrication de boîtes de vitesses, jusqu’au terminal méthanier ou les tramways, en France et à l’international.
Il est l’auteur des ouvrages « Manuel de gestion de projet », « Le pilotage de portefeuilles de projets » et « Gestion de projet avancée » parus chez AFNOR éditions. Il participe régulièrement à l’ouvrage « Management des projets » de l’AFNOR, à la revue « La cible » de l’AFITEP, ainsi qu’à de nombreux forums spécialisés sur l’Internet.
La structuration 3D des projets
Après quelques années de réflexion, j’ai mis au point un outil me permettant de créer bien et rapidement des plannings. Le but initial était de me simplifier la tâche, lors de mes missions de conseil. J’en ai déduis une approche théorique et générale à tous les projets : Le WBS 3D.
La structuration 3D est une méthode permettant de :
Mieux comprendre ce qu’est un projet,
Construire bien et rapidement la planification d’un projet,
Identifier mathématiquement les interfaces d’un projet,
Disposer d’un management de projet intégré.
Le principe du modèle 3D, c’est de comprendre que sur un projet industriel de type EPC (Engineering, Procurement, Construction), par exemple en phase construction : on « installe/construit » des « composants »« quelque part ». Chacun des mots de cette phrase est une dimension ou un organigramme hiérarchique. On trouve dans cette phrase :
Des activités (ABS, Activity Breakdown Structure), « Installer/construire », au sens actions ou processus;
Des produits (PBS, Product Breakdown Structure), « composants », c’est-à-dire des équipements, des matériels ou des ouvrages de génie civil aux plus fins niveaux de l’arborescence. Sur ses étages supérieurs, le PBS est composé de systèmes fonctionnels (SBS, System Breakdown Structure);
Et des zones (GBS, Geographical Breakdown Structure), « quelque part », qui peuvent être géographiques ou fonctionnelles en fonction des phases du projet.
Le WBS (Work Breakdown Structure) résulte du croisement entre le GBS, le PBS et l’ABS, on écrit :
WBS = GBS x PBS x ABS
Par exemple : « Tronçons n°1 – Voie ferrée – Installation » est une tâche du projet.
Ceci se généralise, le WBS d’un projet peut être traduit en bon Français dans toutes les phases du projet.
De plus, la démarche s’applique sur tous les types de projets, qu’ils soient industriels de type EPC, de développement produit/process, IT ou de service.
Les trois arborescences possèdent une chronologie, elles sont projetées sur les axes d’un repère 3D. Il en résulte des petits cubes 3D qui constituent les tâches du projet.
D’autre part, il y a l’organisation qui travaille (OBS, Organization Breakdown Structure), elle représente une quatrième dimension que l’on symbolise par les couleurs des petits cubes 3D (tâches).
La figure suivante représente un projet. L’image du Rubik cube est amusante mais elle est aussi bien appropriée.
La position des petits cubes 3D dans le cube du WBS permet d’identifier les interfaces du projet, tout simplement en mesurant les distances entre les petits cubes 3D, puisque les trois arborescences qui sont projetées sur les axes du cube possèdent une chronologie.
Toutes les intersections ou petits cubes 3D ne sont pas des tâches du projet, il existe un algorithme permettant d’extraire les tâches du cube du WBS : c’est la matrice WBS.
Toutes les disciplines du management de projet tournent autour du cube du projet, que ce soit la gestion documentaire via sa codification, la planification des coûts et des délais, la qualité, etc.
Le point de départ du speaker est qu’un problème est un risque, identifié au préalable ou pas, qui s’est matérialisé. En partant de ce précepte, il devient naturel de manager un problème comme on le ferait d’un risque. En particulier lors de la mise en œuvre du plan de management que nous avons prévu pour ce risque. Il en résulte un registre des problèmes qui ressemble fort à celui des risques avec quelques éléments supplémentaires pour suivre la progression vers la résolution du problème.
Dans un second temps, le speaker propose quelques mesures de suivi de l’ensemble des problèmes que je trouve fort pertinentes. Je leur ajouterais un suivi du nombre total de problèmes ouverts. En effet, une somme de petits problèmes est aussi indicative de dysfonctionnements sérieux qu’un gros problème. Donc, le contrôle de l’évolution de cette métrique est à mettre en place.
Sur ce même sujet du management des problèmes, Seth Godin a publié récemment un billet qui nous rappelle qu’il n’est jamais recommandable d’essayer de cacher un problème voire de refuser de le reconnaître.
Pour avoir une chance de résoudre le problème, il faut d’abord l’identifier !
Selon la définition de Wikipedia, le benchmarking est le processus de comparaison de ses processus métier et sa métrique de performance aux meilleurs de l’industrie et/ou des bonnes pratiques d’autres industries.
Les dimensions typiquement mesurées sont la qualité, le temps et le coût. Dans le processus de benchmarking, le management identifie les meilleures sociétés dans leur industrie, ou dans une autre industrie où des processus semblables existent et comparent les résultats et les processus d’entre ceux étudiés (« les cibles ») à leurs propres résultats et processus. De cette façon, ils apprennent à quel point ces « cibles » fonctionnent bien et, ce qui est plus important, les processus métier qui expliquent pourquoi ces sociétés réussissent.
Le benchmarking de management de projet est le processus consistant à comparer continuellement les pratiques de management de projet de votre organisation avec les pratiques de conduite de projet des leaders n’importe où dans le monde. Son but est d’y gagner des informations pour vous aider à améliorer votre propre performance. Les informations obtenues par le benchmarking pourraient être utilisées pour vous aider à améliorer vos processus et la façon dont ces processus sont exécutés, ou les informations pourraient être utilisées pour aider votre société à devenir plus compétitive sur son marché.
effort continu
Le benchmarking est un effort continu d’analyse et d’évaluation. Un soin particulier doit être mis dans la décision de quoi évaluer. Il est impossible et peu pratique d’évaluer tous les aspects du management de projet. Il est préférable de choisir au final peu de facteurs de succès critiques qui doivent bien fonctionner pour que votre business soit florissant. Pour le benchmarking de management de projet, les facteurs de succès critiques sont d’habitude les processus métier principaux et comment ils sont intégrés. Si ces facteurs clés de succès ne sont pas présents, les efforts de votre organisation peuvent être amoindris.
La décision de quelles informations évaluer est d’habitude plus facile que l’obtention de ces informations. Localiser ces informations exigera une recherche approfondie. Certaines informations peuvent être difficiles à trouver. D’autres informations que vous trouveriez utiles pourraient ne pas être disponibles parce que l’organisation qui les possède les considère comme propriétaires. L’identification des sociétés cibles par rapport auxquelles vous devriez vous évaluer peut ne pas être aussi facile que vous le croyez.
Le benchmarking est devenu plus commun depuis que Xerox l’a popularisé dans les années 80s. Le benchmarking est un ingrédient essentiel pour ces sociétés qui ont gagné le prestigieux Malcolm Baldrige Award. La plupart des lauréats partagent aisément leurs expériences de management de projet. Malheureusement, il y a certaines sociétés vraiment excellentes dans le management de projet qui n’ont pas recherché ces récompenses parce qu’elles ne veulent pas afficher leur excellence.
Le benchmarking de management de projet peut être accompli par des enquêtes, des questionnaires, la tenue des réunions de chapitre locaux du Project Management Institute (PMI®) et en participant à des conférences et symposiums. Les contacts personnels fournissent souvent les sources les plus prisées d’informations.
Il y a un « Code de bonne conduite » pour le benchmarking :
Gardez le processus de benchmarking dans la légalité.
Ne violez pas les règles de confidentialité.
Le partage d’informations est bidirectionnel.
Soyez prêts à signer un formulaire de confidentialité.
Ne partagez pas d’informations reçues avec un tiers sans permission écrite.
Mettez en avant les règles et listes de contrôle mais évitez de demander les formulaires qui peuvent être très sensibles.
Le benchmarking ne devrait pas être exécuté à moins que votre organisation ne soit encline à faire des changements. Les changements doivent faire partie d’un processus structuré qui inclut l’évaluation, l’applicabilité et la gestion des risques. Le benchmarking fait partie du processus de planification stratégique pour le management de projet qui aboutit à un plan d’action prêt à être mis en œuvre.
Jusqu’ici nous avons parlé du benchmarking de projet en matière de comparaison de pratiques de management de projet à celles de concurrents sur le marché. Si nous regardons le benchmarking de management de projet du point de vue d’un modèle de maturité en management de projet, ou PMMM, nous pouvons comprendre comment le benchmarking entre dans la progression et la stabilité de l’organisation et de ses pratiques internes. Le benchmarking, d’un point de vue PMMM, fait partie du Niveau 4: c’est le niveau auquel l’organisation se rend compte que sa méthodologie existante peut être améliorée. La complexité réside à comprendre comment réaliser cette amélioration. Pour des sociétés organisées par projets, l’amélioration continue est le moyen de d’entretenir ou d’améliorer un avantage compétitif. L’amélioration continue est efficacement supportée par le benchmarking continu. La société doit décider qui évaluer et quoi évaluer.
Il y a certaines caractéristiques du Niveau 4 :
L’organisation doit établir un Bureau de Projet pour le management de projet. C’est la position centrale dans la société pour la connaissance en management de projet.
Le Bureau de Projet doit être dédié au processus d’amélioration de conduite de projet. Cela est d’habitude accompli avec du personnel dédié et à plein temps.
Le benchmarking doit être fait tant par rapport à des industries semblables que différentes. Dans le monde actuel, une société de cinq ans d’expérience dans le management de projet pourrait facilement surpasser les capacités d’une société qui a utilisé la conduite de projet depuis 20 ans ou plus.
La société devrait exécuter un benchmarking tant quantitatif que qualitatif. Le benchmarking quantitatif analyse des processus et des méthodologies, tandis que le benchmarking qualitatif regarde les applications de management de projet.
Le Bureau de Projet
Quand les sociétés atteignent le Niveau 4, elles sont engagées dans le management de projet à travers l’organisation toute entière. On y considère la connaissance en management de projet comme indispensable pour la survie de la société. Pour centraliser la connaissance sur la conduite de projet, ces organisations ont créé un Bureau de Projet.
Les responsabilités d’un Bureau de Projet incluent d’habitude, mais ne sont pas limitées, aux choses suivantes :
Un point central de planification stratégique en management de projet
Une organisation dédiée au benchmarking pour la conduite de projet
Une organisation dédiée à l’amélioration continue
Une organisation qui fournit le mentorat pour des chefs de projet inexpérimentés
Une banque de données centralisée sur des leçons apprises
Une organisation pour partager des idées et expériences de management de projet
Une « hot-line » pour la résolution de problèmes qui n’informe pas automatiquement la direction
Une organisation pour créer des standards de management de projet
Un point central pour une planification centralisée
Un point central pour le contrôle des dépenses centralisé et le reporting
Une organisation d’assistance aux Ressources Humaines dans la création d’un parcours professionnel en management de projet
Une organisation d’assistance aux Ressources Humaines dans développement d’un cursus d’études en management de projet
Continuons à explorer ce processus de benchmarking, cette fois en termes d’opportunités de benchmarking.
Historiquement, le benchmarking est accompli par deux approches : benchmarking compétitif et benchmarking de processus. Le benchmarking compétitif se concentre sur des produits et des facteurs de succès critiques quantitatifs. Le benchmarking de processus se concentre sur la performance de processus et la fonctionnalité. Le benchmarking de processus est plus étroitement aligné sur le management de projet. Pour faire simple, nous considérerons seulement le benchmarking d’amélioration de processus. Nous pouvons le découper entre les opportunités d’amélioration quantitative (c’est-à-dire d’intégration) et des opportunités d’amélioration de processus qualitatives.
Les opportunités d’amélioration de processus quantitatives se concentrent généralement autour d’opportunités d’intégration.
Les occasions d’amélioration de processus qualitatives se concentrent généralement autour des applications et de nouveaux changements dans la culture d’entreprise.
Les activités d’amélioration de processus qualitatives incluent :
Acceptation au niveau de l’entreprise : Cela inclut l’obtention que l’organisation entière accepte une méthodologie unique pour manager des projets. La fragmentation des équipes de support au management de projet a tendance à freiner l’adoption rapide du management de projet par l’ensemble de l’organisation. Pour obtenir l’acceptation d’entreprise, nous devons :
Augmenter l’utilisation et le support aux utilisateurs existants
Attirer de nouveaux utilisateurs internes, ceux qui ont résisté au management de projet
Décourager le développement de méthodologies parallèles, qui peuvent créer de nouvelles poches de management de projet. Cela est réalisé en montrant les coûts supplémentaires de parallélisation.
Souligner les bénéfices présents et futurs pour la société qui résulteront de l’utilisation d’une méthodologie unique.
Processus Intégrés : Ceci est la reconnaissance que la méthodologie unique peut être améliorée en y intégrant d’autres processus existants. Typiquement cela inclut des processus métiers comme des prévisions budgétaires d’investissement, des études de faisabilité, des analyses coûts/bénéfices et des analyses de retour sur investissement. Les nouveaux processus qui pourraient être intégrés incluent le management des approvisionnements et des fournisseurs.
Benchmarking Amélioré : Chacun a tendance à s’évaluer par rapport aux meilleurs dans sa propre industrie, mais s’évaluer par rapport à des industries différentes peut être tout aussi utile. Une société d’aérospatiale a passé plus de dix ans à se benchmarker seulement par rapport à d’autres sociétés aérospatiales. Au milieu des années 90s, la société a commencé à s’évaluer par rapport à des sociétés non-aérospatiales et a constaté que ces sociétés avaient développé des méthodologies remarquables avec des capacités excédant celles de cette société aérospatiale.
Améliorations logicielles : Bien que des progiciels sur étagère immédiatement disponibles existent, la plupart des sociétés ont toujours besoin d’un certain type de personnalisation. Cela peut être fait par des améliorations internes de personnalisation ou par de nouveaux développements à la demande, avec le vendeur du logiciel.
Obstacles
Il existe aussi des obstacles à l’achèvement du processus de benchmarking et le passage du Niveau 4 au Niveau 5 du modèle de maturité de management de projet (PMMM). Le benchmarking peut indiquer que les améliorations peuvent être réalisées. Les architectes originaux d’une méthodologie spécifique peuvent résister au changement avec des arguments comme : « ceci n’a pas été inventé ici » ou « cela ne s’applique pas à nous« . Une autre forme de résistance est l’argument que nous nous sommes évalués par rapport à la mauvaise industrie.
Les personnes craignent le changement de manière inhérente et le benchmarking ouvre la porte à des résultats inattendus. Tôt ou tard chacun se rend compte que le benchmarking est une nécessité pour la survie de la société. C’est à ce moment-là qu’un engagement sérieux envers le benchmarking se matérialise.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Le Principe de Pareto: J’y ai pas mal réfléchi récemment…et essayé de voir ma dépense quotidienne de temps et d’énergie de ce point de vue.
Voici la liste rapide des 10 premières choses qui me sont venues à l’esprit :
20 % de mon temps produisent 80 % de ma production de forte qualité.
20 % de mon sommeil produisent 80 % de mon repos.
20 % de mon équipe produisent 80 % de la production.
20 % de mes parties prenantes exigent 80 % de mon attention.
20 % des besoins consomment 80 % de l’effort.
20 % de mon temps de réflexion produisent 80 % des idées.
20 % de mon temps en famille créent 80 % de notre intimité familiale.
20 % de mes tâches devraient certainement être faites par moi et je mets en doute les autres 80 %.
20 % des problèmes nécessiteront 80 % des efforts.
20 % de mon temps produiront 80 % de la solution.
Maintenant la grande question est : « comment puis-je le démultiplier ceci pour y gagner quelque chose ? »
Cela exige beaucoup de discipline! Typiquement, ma liste de tâches est d’habitude une simple liste …encore que, souvent, je place des efforts à prioriser cette liste. Mais même alors, comme j’y regarde de plus près à travers la lentille du 80:20, ma priorisation n’est pas toujours basée sur comment obtenir le meilleur résultat à moindre effort.
Je vais dorénavant prioriser ma liste en me basant sur cela…et voir ce qui arrive. Simple à dire…mais pas si facile à faire !
Information additionnelle: Pour créer un diagramme de Pareto sous MS Excel, suivez ce lien.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
En réalisant une évaluation de Agile, l’autre jour, j’ai pris place dans une réunion de planification de sprint. Bien que nombreux soient projets Agile qui en aient au début de chaque sprint, obtiennent-ils le meilleur du temps et des efforts investis ? En tant que partie intégrante du service fourni à mon client, je lui fournirai une petite antisèche pour la planification de sprint. Ce sera à la fois un guide et un ordre du jour, pour les aider à rester concentrés.
Qu’est-ce que la planification de Sprint (d’itération) ?
Le but de la réunion de planification de sprint est pour que l’équipe s’accorde à compléter un ensemble d’articles de plus forte valeur du «product backlog» (l’arriéré de produit ou liste des articles demandés pour un produit). Cet accord définit le contenu du sprint et est basé sur la vélocité ou la capacité de l’équipe et la longueur du sprint qui est limité dans le temps.
Qui le fait ?
La planification de sprint est un effort collaboratif impliquant :
ScrumMaster – Facilite la réunion
Propriétaire de Produit (Product Owner) – Présente le détail des items du product backlog et leurs critères d’acceptation
Équipe Agile – Définit les tâches et l’effort nécessaire pour accomplir l’engagement
Avant que vous ne commenciez
Avant de commencer nous ne devons assurer que :
Les items dans le product backlog ont été estimés par l’équipe qui leur a assigné une valeur de points d’histoire relative
Le product backlog est trié pour refléter les priorités du Product Owner
Il y a une compréhension générale des critères d’acceptation pour ces items
Les Backlogs
Le product backlog peut adresser aussi bien une nouvelle fonction que des corrections à une fonctionnalité existante. Pour la planification de sprint, les items du product backlog doivent être assez petits pour être achevés dans le sprint et que l’on puisse vérifier qu’ils ont été implémentés correctement. Cette liste d’item du product backlog deviendra le sprint backlog.
Bien calibrer les items du backlog
Les items de product backlog trop grands pour être complétés dans un sprint doivent être divisés en morceaux plus petits. La meilleure façon de les diviser est de se baser sur leur valeur et non pas sur le processus.
Plan basé sur la capacité
Des équipes matures peuvent utiliser la vélocité pour déterminer sur quels items du product backlog s’engager pour le sprint. Des équipes récentes ne peuvent pas connaître leur vélocité ou celle-ci peut ne pas être suffisamment stable pour l’utiliser comme une base de calcul dans la planification du sprint. Une approche pour de nouvelles équipes est de prendre des engagements basés sur la capacité de l’équipe.
Détermination de la capacité
La capacité d’une équipe est tirée de trois mesures simples pour chaque membre de l’équipe :
Nombre d’heures idéales dans un jour ouvrable
Nombre de jours pendant le sprint où la personne sera disponible
Le pourcentage de temps que la personne dédiera à cette équipe
Les étapes de planification
Le Product Owner décrit l’item du product backlog de plus forte valeur
L’équipe détermine les tâches nécessaires de compléter cet item du product baclog
Les membres de l’équipe se portent volontaire pour être propriétaire de certaines tâches
Les propriétaires de tâche évaluent les heures dont ils ont idéalement besoin pour réaliser leur tâche
La planification continue tant que l’équipe peut s’engager à délivrer sans excéder sa capacité
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
“Build your Island” était un concours ludique et pédagogique centré sur les compétences en management de projet de jeunes étudiants.
Les grands principes du concours
Le Projet : gérer un budget de 20 milliards pour construire des îles artificielles, des hôtels et des marinas pour en faire une destination touristique incontournable !
Les outils à la disposition des étudiants : la solution Microsoft Project 2010 (téléchargeable gratuitement) qui leur permet d’exercer en équipe leurs talents de chefs de projet
L’objectif : Obtenir le meilleur retour sur investissement à l’issue des 5 semaines de jeu en ligne pour venir défendre devant un jury composé de professionnels la stratégie qu’ils auront adoptée !
Premier prix : un voyage de rêve en équipe !
Le jeu « Build your Island » proposait aux étudiants une expérience de gestion de projet proche de la réalité. Ils ont ainsi pu découvrir trois aspects de ce métier : la planification c’est-à-dire la création d’un planning représentant les tâches à réaliser, la simulation de différentes stratégies et l’anticipation car les étudiants ont dû s’adapter aux événements imprévus.
Le concours a connu un très grand succès:
Plus de 250 équipes soit plus de 530 étudiants inscrits
64 lycées, écoles et universités
Une communauté très active sur Facebook avec plus de 150 000 vues sur les posts et commentaires!
Les 6 meilleures équipes du jeu sont venues défendre leur stratégie jeudi dernier dans les locaux de Microsoft France devant un jury composé de professionnels de Microsoft, de Teamsquare et de responsables de l’activité projet dans de grands groupes et/ou membres de l’association française du Project Management Institute (PMI) qui travaille sur les bonnes pratiques et la méthodologie dans le management de projet.
L’équipe gagnante Manuia (qui signifie « bonne chance » en Tahitien) a remporté la victoire en mettant en place une stratégie de segmentation de sa clientèle :
Construction d’îles « low-cost » avec de nombreux hôtels pour le tourisme de masse
Construction d’îles luxueuses avec marinas pour agrémenter le séjour de sa clientèle fortunée.
Manuia a ainsi obtenu le meilleur ROI mais également réalisé la meilleure soutenance lors de la finale du jeu. Performance d’autant plus notable qu’étant en plein partiels dans leur école, cette équipe a présenté sa stratégie en live meeting et non en étant physiquement présente à Issy-Les-Moulineaux chez Microsoft comme les 5 autres finalistes !
« Ce qui nous a séduit dans le principe de ce jeu est l’idée de pouvoir faire découvrir la gestion de projet et l’utilisation de Microsoft Project 2010 à des étudiants, tout en restant dans un cadre ludique et d’émulation entre les différentes équipes. Nous avons été très agréablement surpris par l’énergie que certaines équipes ont mis dans le jeu pour comprendre toutes les stratégies possibles ainsi que par l’activité de la page Facebook du concours qui a été un véritable lieu de partage et d’entre-aide entre des équipes pourtant concurrentes ! » Explique Nathalie Hesters, chef de Produit Microsoft Project.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Cette vidéo en anglais créée par Projectmanager.com présente en moins de 10 minutes les principaux livrables du management de projet tout au long du cycle de vie d’un projet. Rien de nouveau mais une présentation visuelle que je trouve bien organisée pour présenter rapidement l’enchaînement des livrables du management de projet. Peut-être à utiliser lors d’une réunion de kick off afin de s’assurer que toutes les parties prenantes comprenne l’approche et la terminologie.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Le storytelling est l’application de procédés narratifs pour renforcer l’adhésion du public à un discours. Il peut être utilisé dans l’industrie, les services, la politique et bien sûr dans le management de projet. J’avais déjà abordé ce sujet auquel je m’intéresse depuis plusieurs années dans le billet Comment créer une culture de « Storytelling » ? qui reprenait la démarche en 6 étapes de Steve Denning (l’un des maîtres incontestés en la matière et que j’ai eu le plaisir de rencontrer) pour créer une bonne culture de Storytelling dans l’organisation.
Voici une vidéo de Darketing sur l’utilisation dans la communication du storytelling. Dans cette vidéo, Sébastien Durand explique comment l’utilisation de l’émotion rend plus réceptif et agit, par le biais de divers « ingrédients », au service des entreprises dans une relation narrateur-narrataire.
Sébastien Durand Conseil aide ses clients à organiser leur stratégie marketing grâce au storytelling ou communication narrative. Il crée ou utilise les histoires des entreprises, des histoires qui font vendre et des histoires qui se propagent.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
PMI a récemment annoncé que la barre des 3 millions de PMBOK en circulation a été franchie !
Je vous rappelle que les membres du PMI ont l’avantage de pouvoir accéder sans frais à la version numérique du Guide PMBOK® (le fichier est encrypté et sa distribution, vente ou reproduction n’est pas autorisée).
Il y a des années il y avait une merveilleuse publicité dont je me rappelle où une matrone nommée Clara Peller jugeait des hamburgers par la quantité de bœuf qu’elle y trouvait. Souvent elle était déçue dans sa recherche et, de frustration, criait « Où est le steak ? ». Wendy’s était la chaîne de restauration qui a inventé cette idée publicitaire et à ce jour la phrase est devenue une accroche pour délivrer de la valeur et répondre aux attentes des clients.
Je pense que Clara était sur quelque chose de vraiment important. Dans mon expérience, les business loupent souvent le « steak » quand ils essayent de délivrer de la valeur à leurs clients particulièrement dans le domaine du logiciel. Je ne sais pas exactement pourquoi. Parfois je pense que les développeurs sont trop distants de leurs clients. Ils peuvent rarement les toucher ou les observer. Ou comprendre leurs vrais défis. Donc ils font des suppositions quand on en vient à la priorisation des besoins puis jettent le logiciel « par-dessus le mur » pour un retour d’information.
Assez souvent ils sont sous pression pour livrer un maelström de fonctionnalités. Même si quasiment personne ne sait ce que sont les besoins clients, donc ils fournissent des solutions en ratissant large espérant atteindre les besoins. En croisant les doigts. Même si cela peut connaître certaines réussites, on aboutit aussi à la livraison de fonctionnalités de faible valeur qui diluent la concentration de l’équipe et augmentent les coûts de développement.
Ne serait-ce pas merveilleux si nous pouvions nous concentrer entièrement sur le « Steak » dans le développement d’application ? Dépenser la majorité de notre énergie, en nous concentrant sur la livraison de solutions à forte valeur et répondant aux plus forts besoins de nos clients. Éliminer le désordre de la déception et de l’ambiguïté et travailler simplement sur qui compte le plus ?
Même si cela ressemble à un conte de fées, les méthodes agiles aspirent justement à atteindre ce but. Mais il n’est pas facile de l’atteindre et le Chef de projet Agile efficace joue un rôle merveilleux dans cette quête. Dans ce billet, je veux partager quelques idées sur la façon de concentrer l’équipe sur la livraison de vraie valeur.
Un « backlog » priorisé !
Un des premiers mécanismes qui pilotent la valeur est le « Backlog de Produit » – la liste priorisée des besoins qui pilote ce que les équipes agiles vont construire. Chaque équipe devrait être focalisée comme un laser sur la priorisation de leur « backlog » de 1 à N. Il ne peut pas y avoir trois ou quatre fonctionnalités de priorité 1, seulement une; puis une seule deuxième, une seule troisième, et cetera.
Croyez-moi, vos clients et parties prenantes voudront jouer indéfiniment avec les priorités. J’ai vu des cas où ils avaient fait des regroupements dans un tableur qui donnaient la priorité de chaque fonctionnalité, puis des sous-fonctionnalités de chacune d’entre elles également priorisées. Ils insisteront pour dire qu’ils ne peuvent pas décomposer davantage la valeur quand ils essaieront d’augmenter la priorité. Cette approche (1.a, 1.b..1.z) leur permet d’échapper à la vraie priorisation et à la sélection. Elle indique aussi leur incapacité innée à faire des choix difficiles quant à ce qui est réellement le plus important. Ne les laissez pas le faire!
Un backlog de produit efficace est toujours dans un ordre linéaire et priorisé. L’équipe délivrera toujours les fonctionnalités de priorité les plus hautes en premier. Ils travailleront d’abord sur celles-ci, les finiront en premier, et s’assureront que le client est bien engagé.
Et, puisque le client est l’arbitre final des priorités, il ne devrait pas vraiment se plaindre de cette approche. Il est vrai qu’historiquement nous leur avons permis de nous donner de longues listes de fonctionnalités sans faire cette distinction et ils sont devenus un peu paresseux.
Quand encouragée à prioriser, je n’ai jamais vu de partie prenante qui en soit incapable.
Valeur Pilotée par le client
La priorisation peut aussi être pilotée par la valeur perçue, le changement, qui devrait être conduit. Une technique utilisée par beaucoup d’équipes agiles est la notion de Poker de valeur. C’est une variation de la populaire technique de Poker de Planification (Planning Poker) qui est utilisée pour l’évaluation de la taille d’une « User Story ». Mais au lieu de déterminer la taille des « User Stories » en points d’histoire, nous utilisons des Points de Valeur comme déterminant.
Dans ce cas vous utilisez un jeu de cartes étiquetées de 1-10, un étant la valeur la plus basse et dix la plus haute. Pour chaque « User Story » ou thème d’histoires vous demandez à un groupe mixte de clients et de parties prenantes ‘de voter’ sur la valeur de l’Histoire. Vous prenez une approche tournante et discutez ‘le pourquoi’ derrière la valeur la plus haute et la valeur la plus basse et vous laissez les membres de l’équipe exprimer leurs avis sur la nuance de valeur.
Une fois que la discussion est finie, vous faîtes un second vote et rediscutez jusqu’à ce que vous rétrécissiez la fourchette de valeurs autant que possible. Parfois vous atteignez un accord sur une valeur de l’ensemble de l’équipe. Parfois vous obtenez simplement une fourchette.
Vous pourriez même compartimenter les valeurs selon les différentes perspectives de l’équipe. Par exemple, les personnes de la qualité et des tests estiment une histoire particulière à cinq, tandis que la valeur des gens du métier cela la valorise à trois et les développeurs ou les gens de la technologie à un. Toutes leurs estimations fournissent des données importantes sur combien vous estimez transversalement la fonctionnalité.
Cette logique pourrait aussi être appliquée à de multiples parties prenantes. Par exemple, les parties prenantes Nord-Américaines pourraient estimer une fonctionnalité à six, tandis que les parties prenantes EMEA la jugent seulement à trois. Dans tous ces cas, discuter de la VALEUR comme d’un attribut distinct aide l’équipe dans la priorisation et dans la décision de combien de finition il faut apporter aux fonctionnalités individuelles.
Une Variation
Une variation vraiment efficace sur la technique de Poker de Valeur est de donner à chaque votant ou contributeur associé un montant de financement à dépenser pour leur vote. Alors, non seulement ils votent sur une valeur, mais ils doivent aussi investir une partie d’un montant fixe de dollars sur la fonctionnalité.
Très souvent de l’argent de Monopoly ou un équivalent amusant sont utilisés à cette fin. Disons que chacun possède 5,000 $ à dépenser sur leurs fonctionnalités pendant le Poker de priorisation. Dans un cas spécifique, une partie prenante vote neuf sur une caractéristique.
Pour souligner l’importance, ils déposent 1,500 $ sur la caractéristique soit environ 30% de leurs fonds disponibles. En fait, ils dépensent leurs fonds sur un total de seulement sept fonctionnalités. Pendant qu’ils continuent à prioriser les fonctionnalités ultérieures, ils ont clairement communiqué leurs avis sur la valeur. En fait, cette caractéristique à 1,500 $ finit en première priorité avec une valeur totale de 12,000 $ à travers l’équipe de vote entière soit 25% des fonds disponibles.
Aussi, voici une question intéressante. Si vous implémentez cette approche, que transmet Priorité n°1 par rapport à Priorité n°1 ET 25% de la valeur ? Selon moi, il y a une grande différence. Cette fonctionnalité représente une part beaucoup plus significative de la valeur et exige un soin particulier dans l’exécution. J’espère que vous voyez la différence.
Souvent dans les équipes agiles, des « User Stories » singulières n’ont pas la masse ou l’impact suffisant pour être estimées efficacement par le client. Plus tôt, j’ai parlé en termes de thème d’histoires. C’est une façon commune de grouper ensemble des histoires qui ont une valeur et de la signification en tant que groupe. Non seulement cela aide dans le développement des jeux de fonctionnalités significatives, mais si vous priorisez au niveau des thèmes, cela simplifie votre priorisation. Cela a aussi plus de signification du point de vue des clients.
Une variation sur ce thème est la Fonctionnalité Minimale Commercialisable (Minimal Marketable Feature : MMF). Ce concept est originaire de Kanban et de LEAN. Essentiellement, c’est comme un thème, mais il apporte les notions de faisabilité, possibilité de commercialisation et l’utilisation d’ensemble client.
Très souvent un MMF est plus grand qu’un thème. Cela pourrait être équivalent à une épopée d’histoires d’utilisateur et exiger que plusieurs sprints soient achevés. Cependant, une fois réalisé, l’équipe délivrera d’habitude physiquement le MMF au client, par exemple, le faisant passer dans l’environnement de production.
Suivi de Valeur
Un des merveilleux ajouts à votre ensemble d’outils de Chef de projet Agile est de brûler complètement la valeur d’histoires, de thèmes, ou MMFs. Vous voudrez installer le graphique de « Burndown Chart » dans un emplacement bien visible qui mette en évidence la valeur livrée par l’équipe. Comme avec tout graphiques « Burndown » vous voudrez garder les yeux de chacun sur le progrès et interagir avec l’équipe sur le progrès et le flux.
Vous voudrez calculer la valeur totale pour une version ou un projet. Alors configurez votre « Burndown » sur une base itération-par-itération.
Si vous obtenez un comportement agile sain dans votre équipe, vous verrez que la valeur est livrée d’une façon chargée sur l’amont. Vous devriez aussi voir les fonctionnalités de forte valeur livrées très tôt. En fait, je m’attends habituellement à ce que des équipes factorisent la valeur dans la qualité globale et dans les stratégies de test.
Savoir conclure
Les chefs de projet Agiles ne se soucient pas juste d’exécuter par cœur de tâches ou des « user stories ». Non! Au lieu de cela ils concentrent leurs équipes sur une vue nuancée et à multiples facettes et vers une exécution orientée client et pilotée par la valeur.
Non seulement espèrent-ils en premier délivrer de la valeur, mais ils espèrent aussi qu’en ce faisant, le client peut atteindre un niveau « assez bon » avec les incréments de produit livrés de façon incrémentale et permettre ainsi à l’équipe d’arrêter le projet plus tôt que prévu.
S’arrêter après la livraison des fonctionnalités et de la fonction qui leur importe vraiment le plus. En quelque sorte atteindre leur valeur et se déplacer ensuite vers le projet suivant de valeur la plus haute. C’est cette sorte de recherche de valeur qui peut vraiment faire qu’une équipe agile se détache de ses homologues traditionnelles et se déplace tellement plus rapidement.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
In a white paper available free of charge IBM proposes a Disciplined Agile Delivery (DAD) process to make the best use of existing Agile methodologies (Scrum, RUP, XP..) while scaling up and putting them in the context of a complete solution life-cycle.
I invite you to read the full introductory document. PMs will find there a terminology they recognize and can easily relate with rather than the sometimes hermetic one of Agile for new comers with its scrums, sprints, poker planning… Through inception, construction and transition phases, the authors position along the DAD Process the tasks to be done, of course in an Agile way and using many of the scrum and RUP techniques .
So, if you’re still Agile adverse, read this white paper, and you may well see some of these approaches like Scrum, XP, RUP in a new and brighter light.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
En juillet 2011, Ken Schwaber et Jeff Sutherland ont édité une nouvelle version du Scrum Guide. Ce “Scrum Body of Kowledge” a l’air anodin, mais du point de vue de Pierre Neis, il annonce de profonds changements dans le “framework”.
« Scrum est en amélioration permanente, pourquoi cette version serait-elle différente des autres? »
Merci à Vincent Capitaine qui nous donne un truc utile pour tous les chefs de projet qui utilisent MS Project 2010.
En tant que chefs de projets, nous imaginons souvent plusieurs scénarios pour planifier nos projets. En créant un fichier MS Project par scénario par exemple, nous pouvons ensuite facilement comparer ces versions du planning tout comme nous comparerions plusieurs versions d’un document Word afin d’en comprendre les différences.
Visuellement, le diagramme de Gantt va indiquer les différence avec des couleurs différentes par scénario et il sera aussi possible de comparer l’impact sur les ressources du projet.
Beaucoup de personnes demandent si le PMI lancera un Corpus des connaissances Agile PMI. La réponse est « Non ». D’une part, il serait presque impossible de se mettre d’accord sur ce qui y entrerait, particulièrement en considérant le désaccord sur ce qui constitue une déclaration officielle sur les structures Agile elles-mêmes (par exemple. Scrum, XP, Kanban). D’autre part, nombreux sont ceux qui pensent qu’un standard officiel Agile serait trop restrictif et irait même à l’encontre de l’intention « adaptative et itérative » du mouvement Agile. Cependant, un Corpus des connaissances Agile PMI n’est pas la seule façon d’avancer. À la place, il y a deux projets passionnants en voie de réalisation qui promettent une nouvelle avancée des techniques Agiles dans la communauté PMI.
1. Une structure de gouvernance améliorée et cohérente : Cela aborde les questions de faire le lien avec la stratégie business, le changement organisationnel et la livraison de projet. En établissant les jeux clairs de rôles et responsabilités qui couvrent non seulement les projets et la structure de contrôle pour le Manager de Programme, mais aussi en s’assurant qu’il y ait une propriété et responsabilité claire de délivrer le changement par le rôle de managers du changement dans le business (« Business Change Managers »). La responsabilité de tout le programme est intégrée dans un unique rôle, le Propriétaire Responsable Senior (Senior Responsible Owner : SRO). Cette structure permet un contrôle hiérarchique efficace de la direction, par le cadre responsable qui s’assure que les besoins business primordiaux restent sous son contrôle stratégique pendant la conception et la livraison tout en suivant le rythme des changements.
5. Une fondation pour l’amélioration de la performance de l’organisation comme le prouvent les mises en place réussies de structure de management de programme à travers le monde. Il y a une industrie accréditée par l’ OGC[1] qui fournit des qualifications, des formateurs, des conseils et des outils pour supporter l’adoption et le développement des capacités des organisations. L’outil le plus important pour cela, du point de vue MSP ™ est P3M3 ™[2], qui fournit un modèle de maturité qui peut être utilisé par les organisations pour cibler leurs investissements et maximiser les bénéfices à court et long termes de l’adoption de MSP.
Jean-Yves Moine, consultant en gestion de projet depuis plus de 15 ans, a exercé pour de grands groupes industriels sur des projets allant de la fabrication de boîtes de vitesses, jusqu’au terminal méthanier ou les tramways, en France et à l’international.
Le benchmarking ne devrait pas être exécuté à moins que votre organisation ne soit encline à faire des changements. Les changements doivent faire partie d’un processus structuré qui inclut l’évaluation, l’applicabilité et la gestion des risques. Le benchmarking fait partie du processus de planification stratégique pour le management de projet qui aboutit à un plan d’action prêt à être mis en œuvre.
Historiquement, le benchmarking est accompli par deux approches : benchmarking compétitif et benchmarking de processus. Le benchmarking compétitif se concentre sur des produits et des facteurs de succès critiques quantitatifs. Le benchmarking de processus se concentre sur la performance de processus et la fonctionnalité. Le benchmarking de processus est plus étroitement aligné sur le management de projet. Pour faire simple, nous considérerons seulement le benchmarking d’amélioration de processus. Nous pouvons le découper entre les opportunités d’amélioration quantitative (c’est-à-dire d’intégration) et des opportunités d’amélioration de processus qualitatives.
Acceptation au niveau de l’entreprise : Cela inclut l’obtention que l’organisation entière accepte une méthodologie unique pour manager des projets. La fragmentation des équipes de support au management de projet a tendance à freiner l’adoption rapide du management de projet par l’ensemble de l’organisation. Pour obtenir l’acceptation d’entreprise, nous devons :
Il existe aussi des obstacles à l’achèvement du processus de benchmarking et le passage du Niveau 4 au Niveau 5 du modèle de maturité de management de projet (PMMM). Le benchmarking peut indiquer que les améliorations peuvent être réalisées. Les architectes originaux d’une méthodologie spécifique peuvent résister au changement avec des arguments comme : « ceci n’a pas été inventé ici » ou « cela ne s’applique pas à nous« . Une autre forme de résistance est l’argument que nous nous sommes évalués par rapport à la mauvaise industrie.
Les personnes craignent le changement de manière inhérente et le benchmarking ouvre la porte à des résultats inattendus. Tôt ou tard chacun se rend compte que le benchmarking est une nécessité pour la survie de la société. C’est à ce moment-là qu’un engagement sérieux envers le benchmarking se matérialise.
20 % de mon temps produisent 80 % de ma production de forte qualité.
La planification de sprint est un effort collaboratif impliquant :
Avant de commencer nous ne devons assurer que :
La capacité d’une équipe est tirée de trois mesures simples pour chaque membre de l’équipe :
“Build your Island” était un concours ludique et pédagogique centré sur les compétences en management de projet de jeunes étudiants.
Premier prix : un voyage de rêve en équipe !
L’équipe gagnante Manuia (qui signifie « bonne chance » en Tahitien) a remporté la victoire en mettant en place une stratégie de segmentation de sa clientèle :
Le storytelling est l’application de procédés narratifs pour renforcer l’adhésion du public à un discours. Il peut être utilisé dans l’industrie, les services, la politique et bien sûr dans le management de projet. J’avais déjà abordé ce sujet auquel je m’intéresse depuis plusieurs années dans le billet Comment créer une culture de « Storytelling » ? qui reprenait la démarche en 6 étapes de Steve Denning (l’un des maîtres incontestés en la matière et que j’ai eu le plaisir de rencontrer) pour créer une bonne culture de Storytelling dans l’organisation.
Sébastien Durand est l’auteur du blog « le blog du storytelling » et du livre « Storytelling- Réenchantez votre communication » (Dunod)e vous rappelle que les membres du PMI ont l’avantage de pouvoir accéder sans frais à la version numérique du Guide PMBOK® (le fichier est encrypté et sa distribution, vente ou reproduction n’est pas autorisée).
Il y a des années il y avait une merveilleuse publicité dont je me rappelle où une matrone nommée Clara Peller jugeait des hamburgers par la quantité de bœuf qu’elle y trouvait. Souvent elle était déçue dans sa recherche et, de frustration, criait « Où est le steak ? ». Wendy’s était la chaîne de restauration qui a inventé cette idée publicitaire et à ce jour la phrase est devenue une accroche pour délivrer de la valeur et répondre aux attentes des clients.
Un des premiers mécanismes qui pilotent la valeur est le « Backlog de Produit » – la liste priorisée des besoins qui pilote ce que les équipes agiles vont construire. Chaque équipe devrait être focalisée comme un laser sur la priorisation de leur « backlog » de 1 à N. Il ne peut pas y avoir trois ou quatre fonctionnalités de priorité 1, seulement une; puis une seule deuxième, une seule troisième, et cetera.
La priorisation peut aussi être pilotée par la valeur perçue, le changement, qui devrait être conduit. Une technique utilisée par beaucoup d’équipes agiles est la notion de Poker de valeur. C’est une variation de la populaire technique de Poker de Planification (Planning Poker) qui est utilisée pour l’évaluation de la taille d’une « User Story ». Mais au lieu de déterminer la taille des « User Stories » en points d’histoire, nous utilisons des Points de Valeur comme déterminant.
Cette logique pourrait aussi être appliquée à de multiples parties prenantes. Par exemple, les parties prenantes Nord-Américaines pourraient estimer une fonctionnalité à six, tandis que les parties prenantes EMEA la jugent seulement à trois. Dans tous ces cas, discuter de la VALEUR comme d’un attribut distinct aide l’équipe dans la priorisation et dans la décision de combien de finition il faut apporter aux fonctionnalités individuelles.
Très souvent de l’argent de Monopoly ou un équivalent amusant sont utilisés à cette fin. Disons que chacun possède 5,000 $ à dépenser sur leurs fonctionnalités pendant le Poker de priorisation. Dans un cas spécifique, une partie prenante vote neuf sur une caractéristique.
Suivi de Valeur
Savoir conclure
In a white paper available free of charge IBM proposes a Disciplined Agile Delivery (DAD) process to make the best use of existing Agile methodologies (Scrum, RUP, XP..) while scaling up and putting them in the context of a complete solution life-cycle.
En juillet 2011, Ken Schwaber et Jeff Sutherland ont édité une nouvelle version du Scrum Guide. Ce “Scrum Body of Kowledge” a l’air anodin, mais du point de vue de Pierre Neis, il annonce de profonds changements dans le “framework”.
Visuellement, le diagramme de Gantt va indiquer les différence avec des couleurs différentes par scénario et il sera aussi possible de comparer l’impact sur les ressources du projet.
DantotsuPM.com 