En management de projets, il n’y a pas de baguette magique mais plutôt un ensemble d’outils, de méthodes et d’approches dont le professionnel a appris à se servir pour satisfaire ses clients et équipes.
Catégorie : outils et méthodes
« Faites semblant avant de faire vraiment ! » : un plaidoyer en faveur du prototypage.
Trop d’équipes sautent directement dans la construction sans même valider leur idée.
« Prototypes: Why You Must Fake It Before You Make It” by Sarah Doody, UX Wizard at Startupfood
Vous pensez avoir une excellente idée ou un projet de start-up ou de nouveau produit ?
Naturellement la prochaine étape serait de le construire, n’est-ce pas ?
Erreur !
Trop d’équipes sautent directement dans la construction sans même valider leur idée. Ensuite, vous vous retrouvez avec un produit fini qui a mille et une fonctionnalités, mais pas d’usage. Personne ne l’utilise, ne l’achète, ne le comprend…
C’est pourquoi le prototypage est crucial pour construire un produit que les gens aiment.
Le prototype vous aide à vous concentrer sur les bons détails et vous évite de perdre un temps précieux et de l’argent.
En résumé : vous devez « faire semblant » avant de le « faire vraiment ».
Dans cet excellent plaidoyer en faveur du prototypage, Sarah Doody partage son expérience :
- Pourquoi ne pas se mettre trop vite à construire
- Comment savoir où vous en êtes
- Un guide pas-à-pas facile à mettre en action pour prototyper des produits qui décoiffent !
Je vous suggère de commencer à visionner cette vidéo 6 minutes après le début ; Durée 30 minutes (plus questions/réponses)
Vous pouvez aussi trouver les diapositives de la présentation ici : http://bit.ly/2vjq5z2
PRINCE2 Agile pour les manager de projet et organisations PRINCE2®
Agile signifie accepter que votre projet ne livrera pas nécessairement tout qui a été spécifié au départ et que, en effet, les utilisateurs n’ont pas nécessairement besoin de tout ce qu’ils ont spécifié.
PRINCE2 Agile for PRINCE2® practitioners
https://www.axelos.com/news/blogs/october-2018/prince2-agile-for-prince2-practitioners par Julia Gosse
A quels défis PRINCE2® les praticiens et leurs employeurs font-ils face avec le concept de livraison de projet Agile ?
Le plus grand défi consiste en ce que le terme « Agile” est souvent mal compris : les gens pourraient faire des raccourcis comme « juste plus vite »; ils pourraient avoir entendu dire que c’est seulement pour les projets informatiques, qu’il relève seulement de Scrum ou que leurs contraintes légales les empêchent d’utiliser.
L’approche Agile
Les projets agiles aboutissent souvent à une livraison plus rapide mais Agile est un état d’esprit. Cela signifie accepter que votre projet ne livrera pas nécessairement tout qui a été spécifié au départ et que, en effet, les utilisateurs n’ont pas nécessairement besoin de tout ce qu’ils ont spécifié.
Quand vos délais sont figés vous devez vous concentrer sur quelles sont les réelles priorités. Se précipiter pour tout délivrer peut diluer le résultat et réduire le niveau de qualité, quelque chose qui reviendra vous hanter plus tard. Un projet Agile préfère ne pas livrer une chose si elle n’est pas à la norme exigée, mais tout dans l’approche est conçu pour s’assurer que ce qui est livré apportera de la valeur au client.
Des approches de livraison Agiles sont de plus en plus utilisées avec beaucoup de succès dans les projets en dehors de l’informatique. J’ai récemment travaillé avec une société d’événementiel utilisant Agile pour planifier et organiser une grande conférence. C’était particulièrement utile pour ce projet qui avait une durée imposée et des coûts fixes.
Davantage d’organisations et praticiens expérimentés avec PRINCE2 gèrent bien cette approche et voient Agile comme un outil très utile. En conséquence, ils adoptent certaines approches comme la co-localisation de l’équipe de projet, l’utilisation d’interactions régulières et la collaboration avec clients et utilisateurs.
Pourquoi le travail avec PRINCE2 Agile est-il efficace dans une organisation PRINCE2 ?
1. Une langue et une approche communes
Vous avez déjà obtenu un niveau de contrôle et une terminologie que vous comprenez et les organisations PRINCE2 sont expertes pour adapter PRINCE2 à des projets différents.
2. Flexibilité avec les méthodes Agiles
Il y a beaucoup de saveurs différentes d’Agile et bien que Scrum soit probablement la plus populaire, ce n’est pas la seule approche de développement Agile. PRINCE2 n’a jamais été normatif dans la définition de comment vous livrez un projet et PRINCE2 Agile peut travailler avec une ou de nombreuses approches Agiles, y compris Scrum, Kanban et DevOps. Cela garantit que l’équipe de management de projet comprend comment s’interfacer avec l’approche de livraison Agile.
Il est important de comprendre que PRINCE2 Agile est toujours centré sur le management de projet et que l’équipe devra être formée dans l’approche (ou les approches) de livraison Agile qu’ils adoptent.
3. Avoir une perspective business
Dans PRINCE2 le manager exécutif représente les intérêts de l’organisation; appliquer ceci à l’environnement Agile est une approche gagnante car vous maintenez la perspective business. Cela assure que les utilisateurs ne se laissent pas emporter par leurs demandes et ce qui est livré répond aux exigences d’affaires. Cela résonne bien dans le monde Agile parce que la livraison de valeur est le principal déterminant pour donner la priorité à ce qui devrait être livré ensuite.
4. L’Agilomètre
Essentiellement c’est un outil d’évaluation de risque pour aider évaluer à quel point Agile est approprié pour un projet donné. Même dans un projet prédictif (en cascade) vous pouvez incorporer quelques éléments Agiles, donc l’Agilomètre permet aux organisations d’évaluer les implications de procéder ainsi.
Dans PRINCE2 Agile® Guidance, on trouve aussi une façon unique d’adresser les questions potentielles liées à l’introduction des méthodes agiles. Par exemple, des assomptions dérangeantes sur les besoins devant être spécifiés au début d’un projet, comment adresser la résistance à un plus grand niveau de collaboration et penser à de la formation ou des ateliers pour encourager l’acceptation d’Agile dans le management de projet.
Pourquoi les praticiens PRINCE2 devraient-ils embrasser Agile?
Les exigences et les attentes des utilisateurs dans un monde de haute technologie augmentent et les gens sont moins enclins à accepter des produits ou des systèmes périmés ou attendre pendant des mois et même des années pour les remplacer.
L’utilisation des apps sur les téléphones portables encouragent des retours et de nouvelles versions fréquentes. Nous devenons tous très habitués du style de livraison collaboratif, itératif et progressif qu’Agile favorise.
L’union des contrôles de management de projet de PRINCE2 avec la connaissance et des capacités Agiles facilite une plus grande adaptabilité aux changements sur les marchés et donne une capacité de répondre et de changer beaucoup plus rapidement.
Qu’est-ce que Agile Hybride en réalité ?
“Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride” ???
What is Hybrid Agile, Anyway?
https://www.agilealliance.org/what-is-hybrid-agile-anyway/ par Becky Hartman, Mike Griffiths, Johanna Rothman, Jesse Fewell, Betsy Kauffman, Stéphane Matola et Horia Slusanschi
Maintenant que le mouvement Agile s’est étendu à de plus grandes organisations dans davantage d’industries, nous voyons énormément de variation. Accordé, nous utilisons une grande variété de structures, techniques et méthodes utilisées, de XP à Scrum à Kanban à la Livraison Continue. Cependant, récemment nous entendons de plus en plus parler d’approches « Hybrides ».
Peut-être avez-vous entendu un dirigeant dire : “Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride”.
Ou peut-être vous avez entendu un consultant déclarer fièrement “À moins que vous ne fassiez beaucoup de prototypage, vous êtes seulement Agile Hybride”. Et ensuite, lors d’une rencontre vous entendez une autre personne dire, “Oh, nous ne sommes pas hybrides, nous utilisons une approche mélangée”.
A travers toutes ces discussions, ce que les gens veulent dire en réalité peut devenir assez confus. Ceux parmi nous qui travaillent sur le prochain Guide de Pratique Agile ont aussi entendu ces points de vue et nous ajoutons qu’une section au guide concentrée sur ce sujet. Voici certains des modèles initiaux que nous voyons…
« Itératif » par rapport à « Incrémental » par rapport à « Agile »
Les cycles de vie des projets suivent un continuum, de prévisionnel (« plan driven ») à Agile. Pour nous aider à comprendre ce continuum, considérons deux des aspects clés de l’Agilité que sont “Livrer Tôt et Souvent” et “S’adapter au Changement”. Si nous devions les tracer sur un graphique bidimensionnel, nous obtiendrions quelque chose comme cela …
Sur le continuum d’approches, depuis prédictives (en bas à gauche) à Agiles (en haut à droite), il y a différents degrés de livraison (incrémentale) et degrés de changement (itératif). Les techniques qui réalisent à la fois de forts niveaux de livraison et de hauts degrés d’adaptabilité sont appelées « Agiles ».
« Mélangé » (Blended) versus « Hybride »
Mais c’est juste trop simpliste. Dans le monde réel, nous n’utilisons pas juste une approche. Nous combinons presque toujours plusieurs techniques différentes. Pour nous aider à comprendre les différentes combinaisons, nous avons posé quelques définitions de travail.
Mélangé Agile (« Blended Agile ») est la combinaison de deux ou plus des méthodes établies, techniques, ou structures Agiles.
En ajoutant un peu de Kanban et des limites de travail en cours (« Work In Progress ») à vos Sprints Scrum, vous obtenez une approche « Mélangée ». Ou peut-être voulez-vous « mélanger » un tableau de visualisation (« Information Radiator ») avec votre approche de livraison en continu. Pour beaucoup de praticiens Agiles, c’est facile à comprendre.
Nous combinons des techniques adaptatives-agressives connues pour être meilleurs dans ce que nous faisons :
Mélangé = Agile + Agile = Meilleur Agile
- Mais en ce qui concerne le reste d’entre nous simples mortels ?
- Et si nous ne sommes pas encore capables d’utiliser ces diverses techniques?
- Et s’il y a contraintes ou demandes qui exigent que quelques éléments non-agiles se produisent ?
Et bien, dans ces cas, vous devriez considérer « l’Hybride »
L’Hybride Agile est la combinaison de méthodes Agiles avec d’autres techniques non-agiles.
Par exemple, un effort important pour détailler les exigences, suivi de sprints de livraison progressive serait une “Approche Hybride”. De même, le prototypage itératif fréquent d’un design, suivi d’une mise en œuvre prédictive avec un plan simple serait “une Approche Hybride”.
Ici, l’idée est de prendre une approche non-Agile et d’y injecter quelques techniques Agiles pour aborder une question ou une opportunité spécifique:
L’hybride = non-Agile + Agile = quelque chose entre les 2 qui a du sens
Quand devrions-nous utiliser des approches Hybrides ?
Comme toute autre chose dans le monde, il y a une bonne et une mauvaise raison de faire quelque chose. Pour être clair, la mauvaise raison de mélanger des techniques est de vouloir faire comme les autres. “Utiliser des techniques Agiles” n’est pas le but. Le but est de livrer le bon résultat business en utilisant les bonnes techniques.
Voici deux scénarios :
1. Hybride comme Adéquat en fonction du but
Pour les projets qui ont un profil de risque inférieur, utilise des approches prédictives pour minimiser les dépenses. Pour des projets de risque plus élevés, utilisez des techniques Itératives pour répéter des activités jusqu’à ce que les problèmes se révèlent et soient résolus. Pour des projets ayant besoin de livraisons agressives, des techniques Progressives livreront quelque chose plus tôt et assureront l’engagement du client. Finalement, pour naviguer dans des environnements complexes, des techniques Agiles peuvent avoir un fort coût initial aérien, mais pourraient le valoir pour les résultats d’ensemble. Chacune a sa propre force. Le mélange de celles-ci de la bonne façon peut mieux répondre à votre contexte que l’utilisation de seulement une d’entre elles.
2. Hybride comme Transition-vers-Agile
Beaucoup d’équipes ne sont pas capables de basculer vers les façons de travailler en mode Agile d’un jour à l’autre. Plus l’organisation est grande, plus ses composantes sont en mouvement, plus longtemps il faudra pour changer. Si vous avez vécu dans un monde prédictif depuis de nombreuses années, les méthodes Agiles paraitront très différentes. En conséquence, votre incursion initiale dans le monde Agile sera un amalgame peu ordonné des deux. C’est OK. Vous utilisez des techniques spécifiques pour vous déplacer dans la direction vers laquelle vous voulez aller.
Chaque projet a des besoins différents. Pour ceux qui se trouvent dans un environnement surtout prédictif, une approche hybride peut être une transition vers davantage d’adaptabilité et de livraisons. Pour ceux qui ont déjà adopté la livraison et l’adaptation agressives, incorporer quelques nouvelles techniques peut encore hausser votre challenge.
Ne déclarez pas simplement “Nous sommes Agiles”, la réalité est que vous utilisez déjà presque toujours une combinaison de techniques différentes. Au lieu de cela, une meilleure stratégie serait de vous poser et de réfléchir à quelles approches seraient les meilleures pour ce que vous voulez réaliser en fonction de là où vous êtes.
la « questiologie », l’art de poser des questions avec Frédéric Falisse
L’une des bases du management de projet est la communication et une communication efficace se base justement sur l’art de poser les bonnes questions !
Coach, conférencier et formateur, Frédéric Falisse a conçu la Questiologie, une méthodologie concrète et accessible pour « poser la bonne question au bon moment ». Car les questions, les bonnes questions, sont notre principal outil de réalisation.
Le management de projet sans drame: est-ce possible ? Un début de réponse avec le modèle maturité TEPEC.
J’ajouterais, est-ce souhaitable ?
En effet, les drames font paraitre ceux qui les dénouent comme des héros. Hors, nombre d’entre nous sont à la recherche permanente de reconnaissance. C’est parfois notre principal moteur. Aussi, consciemment ou pas, certains n’hésiteront pas à monter le moindre tracas en réel danger pour le projet afin d’apparaitre comme des sauveurs quand ils déploieront une solution.
Mais en fait, anticiper les risques et éviter les catastrophes ne font-ils pas partie des motivations fondamentales du recrutement d’un manager de projet ?
Pourquoi le management de projet est-il un processus si fertile en événements, souvent associés à une série de circonstances inattendues, de questions, de problèmes et de risques ?
http://blog.ipma.world/no-drama-project-management-possible/ par Jiwat
Quand on regarde en arrière, la vie ressemble aux épisodes d’une série télévisée avec quelques épisodes emplis de comédie et d’autres pleins de tragédie. Le dictionnaire Oxford définit le drame comme “ Un événement ou circonstance excitant, émotionnel ou inattendu”.
Le management de projet n’est pas étranger aux drames. Des hauts et les bas trop souvent rapportés, des contorsions et des redirections, des excitations et des abattements, bons et mauvais, des succès et des échecs… font penser à certaines personnes que le management de projet est peut-être une production de série dramatique grandeur nature.
Pour développer une compréhension mutuelle, définissons le management de projet sans drame comme étant l’état de cohérence et de stabilité dans la prévision d’événements et le développement dynamique de capacités pendant la livraison du projet pour gérer ces événements comme ils surviennent.
La question est, pourquoi le management de projet est-il un processus ainsi fertile en événements, souvent associé à une série de circonstances inattendues, de questions, de problèmes et de risques ?
Peut-il y avoir un management de projet sans drame ?
Intuitivement, il semble qu’un parfait état de management de projet sans drame est fort peu probable sinon impossible. La raison est que les drames ne sont pas simplement déclenchés par des événements isolés. Les dépendances entre les événements pourraient être assez complexes pour rendre des événements imprévisibles pour l’homme et la capacité de calcul des environnements de projet. Dans de telles circonstances, même si les événements sont prévisibles, les dépendances entre les événements pourraient aboutir à l’apparition de circonstances qui sortent du contrôle d’équipe de projet et dégénèrent en drame.
Avec toute la richesse de la connaissance, des standards et des processus, des outils et des techniques et la nature systémique de livraison de projet; on s’attendrait à ce que les drames puissent être limités à un minimum. Mais, le grand nombre d’échecs de projets, certains en retard et d’autres qui n’émergeront jamais, indiquent que plus doit être fait pour stabiliser les environnements de projet et réduire au minimum les drames.
Étant donné ceci, les clés pour un management de projet sans drame sont la cohérence, la maturité et la résilience. Avec cela à l’esprit, nous proposons 5 éléments dans le modèle de maturité TEPEC qui pourrait aider à atteindre le niveau exigé de cohérence et de résilience à essayer et garder les drames de management de projet au strict minimum.
1. Maturité de pensée et d’action (Thoughts and Actions)
Les environnements de projet sont typiquement intenses et la stabilité de tels environnements exige de personnes qui puissent supporter d’intenses pressions. On considère souvent l’Intelligence Émotionnelle comme un trait de caractère critique pour les gens travaillant sur les projets. Cependant, en raison des nombreuses activités des grands projets, il n’est pas toujours facile ni possible d’avoir en chaque contributeur un certain niveau de processus de pensée ou d’intelligence émotionnelle.
Que faire :
- Réalisez des formations basées sur des scénarios,
- Simulez des exercices de projet, des formations contrôlées en situation ou
- Utilisez des exercices de management de projet virtuels pour aider les gens à développer des compétences de réflexion et de résilience pour le travail de projet.
Comme pour les exercices de management de la continuité business (Business Continuity Management), ceux sur les compétences de réflexion et de résilience devraient être réalisés dans un environnement proche du réel. Ainsi, les personnes peuvent ressentir la façon de répondre et acquérir des compétences qu’elles pourront utiliser dans des situations de vie de projet réelles pour éloigner les drames de management de projet.
2. Maturité environnementale (Environmental)
Construire un environnement interne de projet qui est moins prône aux erreurs, aux crises et aux désastres aide à atteindre un état de management de projet sans drame.
Que faire :
- Avoir des directives claires,
- Communiquer les leçons apprises dans des messages brefs sur une base continue en utilisant les outils des médias sociaux,
- Mener des sessions ‘one-point’ pour mettre en évidence un problème qui a été récemment identifié et discuter des causes et conséquences,
- Construire du ‘Lean Thinking’ dans l’organisation et
- Réaliser des exercices de gestion de crises et de résolution de problèmes.
3. Maturité de processus (Process)
La maturité de processus provient d’avoir établi des processus et des standards de management de projet avec un langage et des structures/méthodologie de management de projet communs et la réalisation d’un ensemble approuvé de protocoles de management de projet à travers toute l’organisation.
Que faire :
- Allez chercher l’appui de cadres supérieurs pour les compétences en management de projet. L’appui du management est critique pour construire la maturité de management de projet,
- Développez des processus et langage standards et choisissez une méthodologie de management de projet spécifique,
- Formez et guidez les gens sur les processus actuels,
- Maintenez des livres électroniques sur les processus,
- Améliorez-vous et élargissez l’influence du management de projet dans l’organisation.
4. Maturité d’exécution (Execution)
L’exécution est l’étape où la plupart des drames surviennent. C’est parce que dans l’exécution, le nombre de personnes et parties prenantes impliquées grandit, les dépendances entre les tâches et les gens augmentent. De plus, l’influence des parties prenantes monte à un niveau tel que des choses commencent à arriver qui sortent des paramètres planifiés. Toutes ces conditions peuvent aboutir à des drames.
Que faire :
- Développez et mettez en œuvre des procédures de qualité pour le travail de projet,
- Inculquez la pensée du risque parmi les gens,
- Établissez et mettez en œuvre des protocoles de management des changements robustes,
- Utilisez un logiciel de management de projet et un système de gestion de configuration pour réduire les erreurs humaines,
- Staffez le projet avec des personnes ayant les compétences et les connaissances exigées pour le travail de projet.
5. Maturité de Gouvernance (Command and Control)
La résilience aux drames de management de projet peut être construite en ayant une gouvernance bien réfléchie et une structure de contrôle.
Que faire :
- Nommez un manager de projet sans drame (Gerardi, 2011),
- Empruntez les procédures HR pour développer des directives pour le travail de projet,
- Ayez une structure de gouvernance claire, des matrices de rôles et responsabilités,
- Exercez la gouvernance appropriée en fonction du contexte de la situation,
- Développez des seuils d’exception et fournissez des directives sur à qui escalader en cas de drames.
Réflexions finales
La poussée pour utiliser le management de projet pour tout type d’activité de développement exige que le management de projet soit moins enclin aux drames. Le modèle de maturité TEPEC est un point de départ pour aider des organisations projets à développer un certain niveau de résilience, de maturité et de cohérence dans leurs environnements pour réduire au minimum les drames et sauver potentiellement du temps et de l’argent pour les clients.
Weighted Shortest Job First (WSJF) est un modèle de priorisation des exigences dans les projets
WSJF est utilisé pour séquencer les travaux dans l’optique de générer un bénéfice maximal: Fonctionnalités, Epics et User Stories Scrum.
Le Weighted Shortest Job First est calculé en divisant le « coût du retard » par la taille de la tâche à réaliser pour répondre au besoin, à l’exigence.
Ce « coût du retard » est la somme de trois estimations :
- la valeur pour le business et les utilisateurs,
- la criticité temporelle et
- la réduction de risques ou création d’opportunités.
WSJF est donc utilisé pour prioriser l’arriéré de produit en calculant le coût du retard par rapport à la taille de la tâche (à défaut de durée).
L’utilisation du WSJF à chaque planning de Release et de Sprint maintient les priorités des arriérés de produit à jour en prenant en compte la valeur pour les utilisateurs et le business, les impacts de délais, les risques et opportunités ainsi que les efforts à fournir pour répondre à l’exigence.
Deux vidéos pour aller un peu ou beaucoup plus loin (en 3 et 20 minutes)
2 pages utiles
- WSJF – Weighted Shortest Job First sur Black Swan Farming
-
Weighted Shortest Job First sur © Scaled Agile, Inc
C’est dans la comparaison relative des WSJF des différents items de l’arriéré de produit et dans la transparence de la priorisation que réside la force de cette technique.
Il me semble qu’il reste aussi à intégrer dans la priorisation les dépendances entre les besoins ou réponses aux besoins qui peuvent grandement influencer le séquencement des travaux.
« Des projets traditionnels aux projets NON traditionnels » par Harold Kerzner, Senior Executive Director for Project Management, IIL
Il est certain qu’il y a une croissance dans l’utilisation de projets non traditionnels et des processus de management de projet qui les accompagnent.
From Traditional to Non-Traditional Projects- https://blog.iil.com/from-traditional-to-non-traditional-projects/ par Harold Kerzner, Ph. D. | Senior Executive Director for Project Management, IIL
Pendant presque quatre décennies, les entreprises au plan mondial ont cherché à créer une méthodologie spécifique qui pourrait être utilisée pour gérer tous leurs projets. Une méthodologie spécifique était une nécessité pour la direction qui était peu disposée à abandonner l’approche “ordonner et contrôler” envers la communauté de management de projet. Des méthodologies ont été conçues pour que la direction puisse conserver un certain degré de standardisation et de contrôle du sommet jusqu’en bas de la hiérarchie. On ne permettait pas à ces équipes de projet de prendre des décisions qui étaient réservées pour les niveaux plus élevés de management. Les cadres exécutifs, le marketing et les commerciaux craignaient le pouvoir et l’autorité que les managers de projet pourraient acquérir.
Les managers de projet actuels ne comprennent pas le degré de défiance que certains d’entre nous ont dû endurer en tant que managers de projet pendant toutes ces années. À ce moment-là, si le choix en avait été laissé aux responsables chez les sous-traitants, les managers de projet n’existeraient pas et tous les projets seraient dirigés par le management fonctionnel, le marketing ou les ventes. Mais les clients et les parties prenantes ont préféré parler directement aux managers de projet (plutôt que de communiquer seulement avec les commerciaux et le marketing) et ont encouragé les sous-traitants à reconnaître le besoin de créer des positions de management de projet.
La croissance des projets non traditionnels
Des méthodologies spécifiques ont fourni aux dirigeants le contrôle qu’ils désiraient, mais il y avait quelques risques. Les cadres exécutifs ont essayé de mettre en application la croyance qu’une méthodologie spécifique était la solution à leurs soucis de management de projet et que « la même méthodologie pour tout » fonctionnait. Ce qui signifiait que chaque projet dans la société devait obligatoirement utiliser la même approche spécifique. Malheureusement, le management sénior a bientôt commencé à se rendre compte que tous les projets ne peuvent pas utiliser une méthodologie « taille unique ». Des projets opérationnels ou traditionnels peuvent être capables de suivre une méthodologie spécifique, mais les projets stratégiques et autres projets non traditionnels devraient être managés différemment.
L’approche que les sociétés ont alors adopté était d’avoir des projets stratégiques et non traditionnels managés par les managers fonctionnels auxquels elles ont alors donné beaucoup de liberté sur comment manager les projets. Les dirigeants ont fait davantage confiance aux managers fonctionnels et les managers de projet n’ont alors plus été perçus comme une menace pour eux.
Au changement de siècle, le nombre de projets non traditionnels augmentait. Plus de confiance était placée entre les mains des managers de projet et des entreprises ont commencé à reconnaître que l’approche « taille unique » devaient être modifiée ou remplacée par des méthodologies ou des structures flexibles, comme Agile ou Scrum, ce qui a redonné plus de liberté et d’autorité aux managers de projet.
L’impact de l’augmentation des projets non traditionnels
Dans certaines sociétés, le nombre de projets non traditionnels était peut-être deux fois plus importants que celui des projets traditionnels comme on peut l’observer au centre du schéma ci-dessous. Comme le besoin de davantage de flexibilité se confirmait dans le management de projet, des changements ont commencé à apparaître dans la façon dont certains des processus traditionnels étaient utilisés.
Les changements dans notre vue des Processus de Management de projet
L’Hexagone de l’excellence
L’hexagone de l’excellence identifie certains des changements que les entreprises ont mis en place comme elles commençaient à utiliser le management de projet sur les projets non traditionnels :
- Processus Intégrés : On attendait maintenant des managers de projet qu’ils prennent des décisions business aussi bien que les traditionnelles décisions techniques ou projet. Aussi, les processus commerciaux ont été alors intégrés avec les processus de management de projet dans des approches flexibles de management de projet.
Culture : Le management de projet a été reconnu comme les processus qui peuvent et vont affecter la société toute entière plutôt que seulement des secteurs fonctionnels spécifiques. Ainsi, une culture de management de projet qui s’appuie sur une coopération concernant l’ensemble de l’entreprise doit être développée et mise en application par la direction.- Support du management : L’appui du management est essentiel. Les membres de la direction doivent se rendre compte qu’il leur faut activement fonctionner comme des sponsors de projet et participer aux comités de direction. Ils doivent aussi se rendre compte que la gouvernance de projet n’est pas la même que la gouvernance fonctionnelle et doivent se montrer désireux de comprendre et accepter les nouveaux niveaux d’autorité, de responsabilité et de processus décisionnel.
- Formation et éducation : Ne former que les chefs de projet ne marche plus. Si une culture de management de projet à la taille de l’entreprise doit être créée, il est possible que toute l’organisation doive recevoir un peu de formation.
- Management de projet informel : Une partie de la formation doit promouvoir les pratiques informelles de management de projet qui sont basées sur des gens qui travaillent ensemble sans avoir à compter sur l’utilisation de rapports hiérarchiques. Les titres et les niveaux d’autorité ne devraient pas être critiques au travail des équipes projet.
- Excellence comportementale : Les formations sur le management des personnes vont se développer. Plutôt que de se concentrer sur les théories comportementales traditionnelles, le focus sera mis sur la communication, la coopération, la collaboration et la confiance, la confiance étant peut-être l’item le plus important.
Capturer les meilleures pratiques
Pendant des décennies, nous avons compté entièrement sur le recueil des meilleures pratiques mais seulement celles liées au management de projet. Aujourd’hui, nous croyons que, si vous managez un projet, vous managez une partie du business et on attend de vous des décisions business aussi bien que des décisions de projet. Donc, nous capturons maintenant les meilleures pratiques dans tous les secteurs du business plutôt que juste dans le management de projet. Ce que nous découvrons est que nous devenons maintenant une partie d’un entrepôt d’informations plutôt qu’une bibliothèque de meilleures pratiques. Comme vu dans ce schéma, nous développons maintenant un processus structuré par lequel on peut découvrir toutes sortes de meilleures pratiques.
Modèles de maturité en management de projet
Des modèles de maturité de management de projet typiques, comme indiqués dans le schéma s’appliquent toujours, mais de nouveaux modèles entrent en scène.
Le Niveau 3 peut être remplacé des méthodologies flexibles plutôt qu’une approche spécifique. On s’attend à ce que le Niveau 4 croissent significativement comme les entreprises se rendent compte que se « benchmarker » / évaluer leur performance par rapport aux sociétés qui sont des leaders mondiaux dans le management de projet peut donner de meilleurs résultats que se comparer uniquement aux sociétés de leur propre industrie. Au Niveau 5, les sociétés démontrent un plus fort empressement à mettre en œuvre des changements qui vont dans l’intérêt supérieur de l’entreprise plutôt que s’inquiéter de leur propre pouvoir et autorité.
PMOs en réseau
Les sociétés reconnaissent le besoin de PMOs depuis plus de trois décennies. Cependant, il y avait des luttes de pouvoir significatives sur quel exécutif conserverait le contrôle du PMO. Il y avait une croyance que “l’information est le pouvoir” et que tout cadre qui contrôlerait le PMO deviendrait plus puissant que ses collègues.
Comme les projets non traditionnels se sont multipliés, il y avait un besoin évident de multiples PMOs. La situation devint plus complexe quand les sociétés commencèrent à s’étendre géographiquement et reconnurent le besoin de PMOs géographiquement distribués. Mais certains cadres exécutifs se sentaient toujours menacés par le concept de PMO et optaient pour la création de PMOs « maître » et « affilié ». Aujourd’hui, ce concept semble avoir reculé comme les entreprises ont reconnu l’importance de mettre en réseau leurs PMOs comme indiqué dans le schéma.
Le changement arrive et il améliorera encore le management de projet
Il y a bien plus d’informations que nous ne pouvions en discuter qui sont liées à chaque composant du schéma d’ensemble et qui résultent de la croissance des projets non traditionnels. Mais il apparaît évident que ce changement arrive et semble être en faveur d’améliorations pour la communauté du management de projet. Où le management de projet nous emmènera, nous ne le savons pas. Mais il est certain qu’il y a une croissance dans l’utilisation de projets non traditionnels et des processus de management de projet qui les accompagnent.
Mind Mapping : À quoi êtes-vous vraiment bon ?
Il se pourrait que le job que vous occupez n’est pas ou plus ce qui vous intéresse désormais car vous avez découvert qu’il existe d’autres choses dans lesquelles vous êtes bien meilleur.
Mind Mapping What are you good at?
http://www.steppingintopm.com/2017/06/discovery-what-are-you-good-at.html par Soma Bhattacharya
Si vous appartenez à un domaine professionnel spécifique ou avez une position enviable, cela signifie-t-il que c’est la seule chose dans laquelle vous êtes bon ? Ou cela doit-il déterminer votre vie pour les trente années à venir ?
Savez-vous que plus de 70 % des travailleurs sont désengagés de leur travail. Cela ne peut être vrai si vous êtes vraiment inspiré par votre profession. Alors, peut être que le job que vous avez n’est pas ce qui vous êtes intéresse désormais car vous avez découvert qu’il existe d’autres choses dans lesquelles vous êtes meilleur.
Prenez Anisha, elle a un travail confortable et l’occupe depuis un moment avant qu’elle ne se réveille un matin et estime qu’elle n’est pas reconnue pour sa loyauté et les longues heures de travail. Elle n’est désormais plus captivée par son travail. Elle cherche quelque chose qui l’excite… Et, que fait-elle ? Elle rejoint la foule des travailleurs démotivés.
Alors, comment découvrir ce que vous voulez faire ou mieux, ce pour quoi vous êtes vraiment bons ?
Fermez vos yeux, imaginez-vous jeune enfant et pensez à ce que vous vouliez être en grandissant. Je voulais être enseignant. Pour moi, c’était la figure du pouvoir en contrôle d’une classe de 60 étudiants. Cela me semblait une position enviable, faite pour moi.
Au fil des années comme nous grandissons et que l’environnement se modifie et que les changements surviennent, nos centres d’intérêt se déplacent, nos compétences prennent forme et nous trouvons un travail.
Dix ans plus tard, est-ce ce toujours que vous voulez ? Comment pouvez-vous prendre le contrôle de votre carrière pour vous assurer qu’elle soit en harmonie avec vos centre d’intérêts ?
Essayez le Mind Mapping, aucun outil miracle ni budget ne sont nécessaires.
- Au centre, positionnez-vous vous même … pensez à tout ce que vous aimez faire ou qui vous rend heureux et écrivez/dessinez. Écrivez autant que vous le pouvez. En face de chaque idée, regardez si vous le faites toujours (exemple : La poésie – j’ai publié un petit recueil ou j’ai un journal caché plein de poésies que j’ai écrites parce que je pense mes amis se moqueront de moi). Rupi Kaur a publié à compte d’auteur son premier recueil de poésies sur Amazon qui est devenu un best seller du NEW YORK TIMES .
- Quand vous avez capturé tout ce que à quoi vous pouvez penser, ajoutez encore 5 choses. Une fois que vous commencez à penser, cela devient facile. Maintenant voyez comment vous pouvez prendre chacune de ces idées et continuer à penser plus profondément à ce qu’elles signifient pour vous. Par exemple, si vous avez mentionné « création », vous pouvez annoter: écrire des billets de blogs, prendre des clichés, créer des blogs de voyage, composer des articles pour des magazines, devenir un auteur…
Une fois toutes ces idées complétées, prenez un stylo de couleur différente et cherchez des modèles récurrents. Les choses communes qui émergent. Ce pourraient être la similitude dans les idées/catégories principales ou des sous-catégories dans les catégories. Prenez en note.
- Pouvez-vous maintenant voir la tendance ? Qu’aimez-vous vraiment faire ? Dans la plupart des cas, vous pouvez aussi voir une profession prendre forme. En face de la profession (ou centre d’intérêt) que vous avez trouvé, essayez d’ajouter des façons dont vous pourriez la réaliser ou en faire de l’argent. Cela peut apporter de la clarté : Si c’est quelque chose dont vous voulez faire une profession, ou pour laquelle vous voulez vous préparer, comme passer des certifications ou en parler avec des amis ou contacts qui sont déjà dans la profession de votre choix.
C’est votre décision. Vous n’avez pas à renoncer à votre travail pour vous lancer, mais si cela signifie vraiment quelque chose pour vous, pensez-y. Réfléchissez à comment vous pouvez tenter cette opportunité.
Cela peut être une merveilleuse façon de vous retrouver et d’être à nouveau inspiré.
Alors, avez-vous découvert ce pour quoi vous êtes bon ?
connaissez-vous la Méthodologie de gestion de projet PM² ?
PM² est une méthode de gestion de projet développée et promue par la Commission Européenne.
Elle est basée sur l’expérience des institutions européennes en matière de gestion de milliers de projets, d’initiatives de changement, de programmes et de fonds.
OpenPM² est une version gratuite de PM² qui a été développée pour répondre aux besoins spécifiques, à la culture et aux contraintes des Institutions Européennes et de l’administration publique, tout en intégrant des éléments issus des meilleures pratiques, normes et méthodologies d’importance internationale, telles que PRINCE2, le PMBOK du PMI et l’IPMA. Le résultat est une méthodologie facile à mettre en œuvre et adaptée à toutes les organisations, publiques et privées.
L’initiative OPEN PM²
Jusqu’en 2016, la méthodologie et la certification PM² n’étaient ouvertes qu’au personnel des Institutions de l’Union Européenne. Avec l’initiative OpenPM², la Commission Européenne a décidé de rendre la méthode de gestion de projet PM² disponible même en dehors des Institutions de l’UE, en la mettant à disposition des contractants, des États membres et enfin des citoyens de l’Union.
Cette initiative aide à mettre en place un langage de gestion de projet commun à toutes les organisations et à accroître l’efficacité, la collaboration et le succès dans la coordination de projets au sein de l’Union Européenne.
L’objectif de l’initiative OpenPM² est de favoriser une meilleure gestion des projets au sein de l’Union Européenne afin d’aider les organisations à relever des défis tels que : la collaboration avec d’autres organisations, l’implication des citoyens et la gestion des prestataires de services externes.
Davantage de détails
Notre partenaire, QRP International, organise des formations sur les principes fondamentaux PM², consacrées à l’étude de la méthodologie de gestion de projet PM². Les formations durent 2 jours et se déroulent à Bruxelles dans le quartier de la Commission européenne.
AgileSHIFT : Poser un cadre d’ensemble pour Agile, par Henny Portman
De trop nombreuses organisations ont du mal ou même échouent purement et simplement à mettre en œuvre des structures pour accroitre leur niveau d’agilité.
Une des raisons est la rupture de culture entre une organisation traditionnelle et la culture agile. Mettre en place des structures de livraison Agiles seulement dans votre service informatique ne suffit pas.
AXELOS a développé un cadre de référence qui prépare les gens au changement transformationnel en créant une culture d’agilité d’entreprise. La structure AgileSHIFT aide les organisations à réaliser un changement transformationnel, à adopter une mentalité ‘ survivre, rivaliser et prospérer. Elle aide à construire un pont entre l’état actuel et l’état cible (le Delta dans AgileSHIFT) en embrassant un ensemble d’approches agiles, structurées et hybrides à travers toute l’organisation. La déconnexion existante entre ‘Faire tourner la boite’ et ‘Changer le business’ disparaît (Run the Organization et Change the Organization).
Chaque personne est une activatrice de changement, encouragée et autorisée à faciliter cette évolution.
Télécharger : AgileSHIFT (QRC, 181012) v1.0
Le cadre de méthode AgileSHIFT explique pourquoi nous avons besoin de l’agilité d’entreprise. Il y a une rapidité d’occurrence des changements qui accélère : volatilité, incertitude, complexité, ambiguïté (VUCA). Le rôle de la technologie évolue de « supporté par la technologie » vers « la technologie au centre de tout » en passant par « facilité par la technologie » . L’écart augmente entre l’état actuel et désiré pour votre organisation. Les influences perturbatrices comme le travail à distance, le stockage dans le cloud, la présence en ligne, les marchés inefficaces et des événements totalement inattendus contribuent à ces évolutions forcées.
Pour leur faire face, nous devons adopter le cadre et la structure proposés par AgileSHIFT qui définissent l’agilité d’entreprise, ses principes et ses pratiques. L’agilité d’entreprise est la capacité d’une organisation à bouger et s’adapter rapidement pour répondre aux changements des clients et des besoins du marché.
Les cinq principes
- Le Changement se produira aussi embrassez le statu quo
- Challengez le statu quo
- Développez un environnement où chacun ajoute de la valeur
- Concentrez-vous sur la co-création de valeur pour le client
- Adaptez votre approche
Les cinq pratiques
- Planifiez d’être flexible et adaptable
- Engagez avec les parties prenantes
- Construisez des équipes collaboratives
- Concentrez-vous sur la co-création de valeur
- Mesurez cette valeur pour le client
Le comment (correspond à l’approche de livraison AgileSHIFT)
Il s’exprime dans la structure AgileSHIFT par les rôles, le « workflow » (flux de travail) AgileSHIFT, une approche itérative et des outils et techniques.
Il y a 3 rôles : l’équipe AgileSHIFT, le sponsor et le coach.
Une approche itérative simple y est expliquée mais selon la situation vous devrez choisir la bonne approche. Les outils et des techniques incluent les histoires client (User Stories) et les épopées (Epics), les estimations relatives et les points d’histoire, la liste des tâches et la « roadmap » (feuille de route) AgileSHIFT, l’essaim, kanban, des canevas et agendas.
Des téléchargements sont disponibles pour les deux derniers.
Pour montrer votre compréhension d’AgileSHIFT, une certification basique et de praticien seront possibles.
Dans l’image suivante, Henny Portman a positionné AgileSHIFT par rapport aux autres approches et méthodes.
Pour aller plus loin, un wébinaire en langue anglaise est proposé par Axelos
le 31 Octobre à 8:00 GMT : An agile solution for the entire organization: Introducing AgileSHIFT®
L’avenir de la gestion de projet avec Microsoft Project (Whitepaper Campana & Schott)
Retour sur les innovations et la nouvelle feuille de route PPM annoncées par Microsoft à Orlando.
Microsoft vient de présenter de nouveaux modules, la feuille de route officielle et d’autres détails sur les outils PPM Microsoft. Les principaux sujets et points clés de la feuille de route pour la gestion de projet et le management de portefeuilles de projets sont les formes modernes de travail collaboratif et tirent tous les avantages du « cloud ». Certaines innovations inattendues ont particulièrement retenu notre attention.
Découvrez ici le retour de Campana & Schott sur les nouveautés et le potentiel de la nouvelle feuille de route Microsoft pour la gestion de projet et de programme.
apprendre à utiliser les cartes d’empathie permet de construire de meilleures solutions
Use Empathy Maps to build better software
https://blog.agilistic.nl/understand-your-users-with-an-empathy-map/ par Christiaan Verwijs
La construction de produits formidables exige une compréhension profonde, emphatique de vos utilisateurs. De quoi ont-ils besoin ? Qu’est-ce qui les motive ? Quelle est leur expérience du produit ou processus spécifique ?
Dans ce billet, j’explique comment utiliser des Cartes d’Empathie et des interviews avec des utilisateurs pour construire cette compréhension.
À propos des Cartes d’Empathie
Les Cartes d’Empathie sont un outil simple et puissant pour construire une meilleure compréhension de vos utilisateurs. Il est pas étonnant qu’elles soient les basiques des UX-designers et généralement utilisées dans le Design Thinking. Le nom provient de “Empathie”, qui se réfère à la capacité de comprendre ce qu’une autre personne pense et ressent.
Une recherche Google ramène beaucoup de modèles différents, mais je trouve celui ci-dessous le plus pratique et complet : http://www.eventmodelgeneration.com/empathymap/
Vous pouvez créer une Carte d’Empathie commune à tous les utilisateurs, ou des cartes différentes pour de multiples segments ou utilisateurs individuels.
Dans tous les cas, les meilleures Cartes d’Empathie sont basées sur des données réelles. Pas sur des conjectures ou des suppositions que vous feriez dans votre équipe. Cela signifie qu’une bonne Carte d’Empathie exige de sortir de nos bureaux pour aller discuter avec de vrais utilisateurs en chair et en os.
Comment construire une Carte d’Empathie
- Avec votre équipe (Scrum), identifiez des utilisateurs ou des clients que vous pouvez interviewer pendant 30 à 60 minutes. Si vous interviewez plusieurs personnes, essayez de trouver différents types d’utilisateurs. Incluez des utilisateurs insatisfaits chaque fois que possible. Leur perspective apporte souvent des vues qui vous questionneront.
- Préparez l’interview avec votre équipe. Créez une liste de questions ouvertes qui vous aident à comprendre les utilisateurs. Bien que nous soyons au final intéressés par construire un bon produit, les Cartes d’Empathie ne sont pas destinées à évaluer seulement des idées de produit. Concentrez-vous sur l’utilisateur : Quel genre du travail fait-il ? Quels sont les défis auxquels il fait face dans son travail ? Qu’est-ce qui le frustre ? Qu’attendrait-il d’un nouveau produit ? La Carte d’Empathie affichée ci-dessus donne des idées des sortes de questions que vous pouvez poser.
- Si c’est la première fois que vous allez interviewer des utilisateurs, il pourrait être avantageux de tester d’abord les interviews dans votre équipe. Pratiquez à tour de rôle en posant des questions ouvertes et en prenant des notes en même temps.
Interviewez les utilisateurs. Vous pouvez le faire avec l’équipe ou vous pouvez vous séparer en binômes. Assurez-vous que chacun dans l’équipe soit impliqué dans le processus. Prenez des notes pendant l’interview ou enregistrez-le (avec la permission de l’utilisateur, évidemment).
- Quand vous avez fini de mener les interviews, réunissez votre équipe pour synthétiser l’information et en extraire les points clefs de compréhension des attentes. Utilisez de grands posters avec une Carte d’Empathie, capturez les compréhensions, les citations d’utilisateurs et leurs comportements sur des post-it et positionnez-les dans les secteurs correspondants sur la carte.
- Quand vous avez fini de créer ces cartes, discutez-en en équipe. Que vous disent-elles ? Quelles compréhensions avez-nous recueillies ? Vous pouvez ou utiliser les cartes elles-mêmes comme point d’entrée à la génération d’idées ou vous pouvez poursuivre avec d’autres techniques (comme le brainstorming, la visualisation du parcours client, etc).
Comment faire une bonne utilisation des Cartes d’Empathie
Il n’est d’aucune utilité de construire une Carte d’Empathie que l’on ne regarde jamais. Les cartes d’empathie nous permettent de voir notre produit avec les yeux de nos utilisateurs. Cette perspective est facilement perdue au fil du temps, rendant d’autant plus important de garder les utilisateurs tangibles et visibles.
Ci-dessous, deux ou trois astuces :
- Les cartes d’Empathie peuvent facilement être métamorphosées en Personas. Un Persona est un utilisateur factice (ou parfois réel). Les Personas décrivent des caractéristiques majeures, des comportements et des attentes. Une façon de le faire est décrite ici.
- Certaines équipes encadrent leurs Cartes d’Empathie et les placent quelque part bien en vues. J’ai une fois formé un groupe d’équipes chez ProRail à le faire. Ils ont aussi créé des Personas basés sur de vraies personnes et ont invité ces gens (de temps en temps) à suivre les Revues de Sprint.
En l’absence d’utilisateurs réels, les Personas et des Cartes d’Empathie sont utiles pendant la Planification ou les Revues de Sprint. Parce qu’ils rendent les utilisateurs tangibles et visibles, ils nous aident à regarder notre produit à travers leurs yeux. Comprendraient-ils cette nouvelle fonctionnalité ? L’aimeraient-ils ? Qu’est-ce qui pourrait être frustrant pour eux ?
Bonne chance dans la construction de vos Cartes d’Empathie!
Partagez ce que votre équipe a appris à travers ce processus lors de leur construction. Postez vos exemples de bonnes et vraies Cartes d’Empathie.
Le Système d’Information des Ressources Humaines ou SIRH : 50 nuances plus claires ! Par Yohann Romand
Dernier volet de la saga SIRH 50 nuances de projets : Yohann ROMAND vous y dévoile ses dernières instructions afin que vous passiez à l’acte !
Comment mesurer le Retour sur Investissements (Return On Investment ROI) d’un Système d’Information des Ressources Humaines ou SIRH ?
En clair, vous l’aurez compris, la mise en place d’un SIRH ou le changement du SIRH existant est un véritable projet mobilisant un grand nombre de parties prenantes, pouvant exiger une charge de travail très importante ainsi qu’un coût non négligeable ! Il est important d’en mesurer le ROI.
Parce qu’il est souvent compliqué pour les DRH de convaincre leur direction d’équiper l’entreprise d’un SIRH ou de moderniser l’existant ; estimer et mesurer les gains et bénéfices, le retour sur investissement s’avère de fait, primordial pour légitimer cet investissement.
Vous souhaitez passer à l’acte pour réussir le déploiement ou la modernisation de votre SIRH ?
Domination 1 : Mesurer le temps passé sur les tâches à faible valeur ajoutée !
Beaucoup trop de tâches non automatisées par un SIRH génèrent un temps de ressaisie considérable et souvent sous-estimé : capture des entretiens annuels papier pour analyse et temps de contrôles sur la paie en sont deux exemples majeurs.
Estimer le nombre en jours / homme économisés par l’automatisation de ces tâches permet d’évaluer le gain en équivalent temps plein (ETP) et prévoir ainsi, une optimisation de l’équipe RH sur la partie administrative que l’on pourra valoriser sur des tâches à plus forte valeur ajoutée ou gagner en ETP dans l’équipe.
Domination 2 : Repérer les bénéfices liés à une meilleure gestion des collaborateurs !
Se doter d’un SIRH performant permet d’améliorer considérablement la prise en compte des attentes des collaborateurs.
L’analyse plus pertinente des entretiens, de leurs souhaits d’évolution, de leurs besoins en formation, une analyse plus fine de la correspondance des compétences disponibles versus les postes à pourvoir, ou une compréhension précise des arrêts maladie… permettent d’être plus à l’écoute, de mieux gérer les carrières, d’améliorer le climat social et in fine, d’agir sur le taux de Turnover, le taux de rétention des salariés et / ou d’améliorer la pertinence des recrutements.
Ces indicateurs sont plus difficilement mesurables mais doivent être mis en avant pour valoriser la nécessité d’un SIRH.
Domination 3 : ROI qualitatif ou gains cachés !
A l’heure du digital et des innovations technologiques, se doter d’un SIRH moderne et performant peut avoir un impact ‘indirect’ en termes de ROI, notamment sur l’image employeur, son agilité …
Objet sexy le SIRH ? Définitivement oui, il contribue en effet à rendre l’entreprise plus attractive tant pour les recrutements que vis-à-vis des marchés extérieurs !
Domination 4 : Le ROI dans le choix de la solution !
Le calcul du ROI peut être déterminant dans le choix de la solution : Enterprise Resource Planning (ERP) versus ‘Solutions expert’, ‘Licence’ versus ‘Software As A Service (SAAS)’, ‘Internalisation’ versus ‘Externalisation’ ?
Le coût d’un logiciel maintenu à jour par l’entreprise, hébergé sur les serveurs de l’entreprise, répondant aux critères de sécurité doit être précisément calculé et comparé au choix d’une solution SAAS, facturée plus cher par l’éditeur, mais tout compris. Est-ce qu’une acquisition en licence est réellement moins chère ? Externalisation versus internalisation : si j’externalise, quel est le gain en ETP versus le différentiel de coût facturé ?
Épilogue…
Vous aurez compris que la performance RH n’est pas qu’une notion abstraite mais bien mesurable au travers de Key Performance Indicators (KPI) qui permettront de mesurer le Retour sur Investissements (Return On Investment ROI) du SIRH.
Ces indicateurs de performance peuvent être multiples et variés, opérationnels ou plus qualitatifs. Ils devront être toutefois adaptés à votre contexte et à vos pratiques RH.
Le calcul du ROI ne s’arrête pas au choix d’un SIRH mais doit permettre à votre entreprise de s’inscrire dans une démarche d’amélioration continue !
Domination finale : le choix de l’outil
Si vous êtes à la recherche d’un pilotage simple et efficace, IQar, a conçu et développé SuiteProG, logiciel de pilotage du portefeuille des projets pour une gestion rentable et opérationnelle de vos projets ! Résistez-vous à la tentation ?
Auteur : Yohann Romand, Consultant Senior Projets, Cabinet conseil dans la gouvernance du portefeuille des projets IQar, www.iqar-france.fr
le « Standard for Organizational Project Management » 2018 du PMI®
Ce standard est l’un des derniers du PMI et il est aligné sur « A Guide to the Project Management Body of Knowledge » (PMBOK® Guide) – Sixième édition et les autres standards du PMI.
Organizational Project Management (OPM) est la structure utilisée pour aligner les pratiques de management de projets, programmes et portefeuilles sur la stratégie et les objectifs de l’organisation. Elle permet d’adapter ces pratiques au contexte, à la situation et à la structure de l’organisation.
OPM fournit des conseils à la direction de l’organisation, au personnel du bureau de projet (PMO) et aux praticiens sur ces sujets.
OPM couvre tout le panorama de la fourniture de valeur par les projets et peut être utilisé avec toutes les approches de projets, y compris les pratiques prédictives dites en cascade, agiles, itératives, hybrides…
OPM est particulièrement bénéfique pour les organisations qui n’ont pas une approche de management de projet unifiée et celles qui cherchent à l’améliorer.
“PMI,” the PMI logo, “OPM,” “PMBOK” “and “Project Management Institute” are registered marks of Project Management Institute, Inc.
Comment développer un plan de contingence pour mieux manager vos risques ?
Un plan de contingence n’est pas là uniquement en cas de désastre !
A contingency plan isn’t just exclusively for calamities.
https://www.project-management.pm/contingency-plan/
La mise sur pied de plans de contingence, c’est surtout de la planification et préparation en cas de matérialisation de certains risques comme la perte ou le manque de personnels, clients, données, budget ou autres facteurs qui impacteraient votre projet. C’est pourquoi chaque projet ou business existant doit avoir un plan de contingence pour y gagner un flux de travail harmonieux et aborder plus facilement problèmes et menaces.
La puissance de l’évaluation de risque
Dans chaque projet, un leader doit être expérimenté en management des risques quand il crée le plan de contingence. Les deux aspects doivent être coordonnés l’un avec l’autre pour clairement identifier les éléments qui pourraient perturber le déroulement du projet.
Un plan de contingence entre en jeu quand le plan original ne fonctionne pas. C’est pourquoi il est souvent appelé plan de secours.
Ci-dessous sont les pratiques à mettre en œuvre pendant votre processus d’évaluation de risque :
- Examinez le business opérationnel en entier, particulièrement ces aspects les plus critiques. Un bon plan de contingence doit mettre en évidence les méthodes pour atténuer les risques existants ou imprévus.
- Définissez exactement quels sont les risques. Pour définir clairement et précisément les différents risques, vous devez conduire une Analyse de Risque. Ceci vous aidera si à identifier les menaces ou les risques possibles qui saperont votre projet ou business.
- Priorisez les risques. La mise sur pied de plans d’urgence implique une planification intelligente des composantes du projet. Sinon, vous vous perdrez dans une multitude de plans à définir avec trop peu de temps. Votre plan de contingence doit être équilibré et organisé, donc vous devez identifier les priorités. Cela aidera aussi votre équipe à répondre du tac au tac si une crise devait survenir.
Le développement de votre plan de contingence
Voici les éléments à garder à l’esprit en développant et préparant votre plan :
- Maintenir votre processus métier.
- Avoir un échéancier et des délais définis. Organisez vos tâches dans votre plan de contingence en fonction de combien de temps il faudra pour les exécuter.
- Déterminer la cause, le déclencheur. Qu’est-ce qui vous fera mettre en œuvre le plan de contingence ? Décidez du plan d’actions nécessaires et des personnes responsables des tâches à faire.
- Simple est mieux. Abstenez-vous d’utiliser un vocabulaire trop complexe. Fournissez un plan de contingence clair et bref.
Garder à l’esprit vos ressources. Pensez à l’impact de votre plan de contingence sur votre organisation.
- Standardiser votre plan. Assurez-vous que chacun connait le plan et est toujours informé des nécessaires mises à jour.
- Implémenter le management de risque. Trouvez des méthodes pour atténuer ou éliminer les risques de votre plan de contingence.
- Documenter. Mettez tout par écrit jusque dans chaque petit détail et n’oubliez pas d’en faire de multiples copies.
La mise à jour de votre plan de contingence
Une fois que vous avez votre plan, il est temps d’en assurer la maintenance nécessaire pour le garder adapté à ce projet et à de futurs projets et business.
- Disséminez l’information du plan à chacun.
- Laissez toutes les personnes impliquées connaitre leurs tâches et devoirs vis-à-vis du plan de contingence.
- Facilitez la formation et organisez des entrainements si nécessaire.
- Évaluez constamment les changements et ajustez si nécessaire.
- Communiquez les plans révisés à l’organisation toute entière et assurez-vous que le plan de contingence précédent est éliminé.
- Gardez les documents de votre plan accessibles pour future référence et usage.
- Conduisez régulièrement des analyses et évaluations pour vérifier le processus.
En somme …
La réalité est qu’un plan de contingence est souvent sous-estimé ou négligé dans les organisations parce que les managers croient qu’ils pourront facilement résoudre le problème, pourvu qu’ils en soient conscients et bien informés.
La mise sur pied de plans de contingence est un investissement à long terme et les organisations ont besoin d’y consacrer du temps et de l’argent pour garantir que leur projet est entre de bonnes mains.
Comment naviguer sur votre océan de TO-DOs (choses à faire) ?
C’est déjà la rentrée et votre liste de choses à faire ne cesse de s’allonger ?
How to Master an Ocean of To-Dos with Two Simple Tools
https://betterhumans.coach.me/turn-your-tidal-wave-of-to-dos-into-the-ride-of-a-lifetime-37e21fbc3c9 par Dr. Albert J Viljoen
Priorisez selon l’impact et l’effort
C’est un petit dispositif que j’ai tiré de ma participation avec des start-ups. Il s’appelle la Matrice Effort Impact.
Vous devriez le remplir juste après avoir complété votre Matrice de Eisenhower (ou de Adair).
Étape 1 : Dessinez le diagramme suivant sur une feuille blanche :
MATRICE EFFORT – IMPACT
| DIFFICILE | FACILE | |
| FORT IMPACT |
1 |
2 |
| FAIBLE IMPACT |
3 |
4 |
Étape 2 : Retournez à votre liste de toutes les tâches et distribuez-les dans ces quadrants.
Étape 3 : Prenez SEULEMENT les tâches que vous mettez dans le quadrant 2 et bossez dessus.
Vous remarquerez que cette matrice ne fonctionne pas seulement dans les quadrants, mais aussi à cheval sur plusieurs pour certaines tâches. Cela nécessite donc un peu de réflexion pour décider de quelles tâches sont les plus faciles et lesquelles vous donneront les plus forts retours sur investissement.
Exemples
Quadrant 1 : Fort Impact, Difficile.
Créer une société et la faire entrer au « Fortune 500 ». Écrire d’un roman à succès. Inventer l’ampoule. Démarrer une colonie sur mars. Faire passer votre enfant à l’âge adulte. Cela peut vous coûter du sang, de la sueur, des larmes et de l’argent, mais cela vaudra le coup au final.
Quadrant 2 : Fort Impact, Facile
Un rendez-vous réussi. Sortir votre vidéo promotionnelle. Faire ce que vous savez bien faire au lieu d’essayer quelque chose que vous n’avez jamais fait auparavant.
Le truc avec ce quadrant est que nous ne savons pas toujours laquelle de nos tâches aura le meilleur impact. C’est le quadrant dans lequel nous souhaitons que soient positionnés nos efforts. Mais ils ne s’y trouvent pas souvent. Si vous avez réellement des tâches dans ce quadrant, vous devriez les mettre au sommet de votre liste.
Quadrant 3 : Faible Impact, Difficile
Distribuer votre matériel promotionnel. Vendre quoi que ce soit à domicile. Essayer de faire changer d’avis votre conjoint.
Celles-ci sont presque pires que le quatrième Quadrant d’Eisenhower, parce qu’elles ne procurent même pas de plaisir. Je les rayerais probablement de ma liste et c’est tout, ou, si elles doivent réellement être faites ? Déléguez-les le plus possible !
Quadrant 4 : Faible Impact, Facile
Faire de vos amis des clients en échange de témoignages. Faire faire de nouvelles cartes de visite. Envoyer la facture mensuelle à votre client.
Ces tâches ne vont pas nécessairement changer la face de la terre, mais elles ne prendront pas trop de temps ni d’énergie. Plus important encore : si vous avez beaucoup de celles-ci, leur valeur s’additionne !
Le coût du retard peut-il être évalué quantitativement ?
A défaut de bénéfices clairs au niveau du projet, le coût du retard à ne pas avoir le livrable du projet peut permettre une priorisation.
Cost of Delay. Can It Be Quantified?
https://www.leadingagile.com/2017/06/cost-delay-project-management-2 par Marty Bradley
La plupart des organisations ont du mal à déterminer combien de revenu chaque projet va créer. Donc, elles ont besoin d’un autre critère pour prioriser leurs arriérés de développement. C’est la raison pour laquelle je vois de plus en plus de sociétés se tourner vers le Coût de Retard (Cost of Delay – CoD). Souvent, j’entends les gens parler du CoD comme si c’est une formule mathématique avec laquelle ils peuvent calculer des revenus tangibles, obtenir un résultat et que chacun va pouvoir facilement comprendre. Selon mon expérience, ce n’est pas le cas.
La réalité est que, dans la plupart des cas, le coût du retard (CoD) est constitué de plus que seulement des Euros ou Dollars. Le coût est d’habitude quelque chose de plus ambigu, comme Jim Hayden l’a indiqué sur son blog et c’est là que les gens s’embrouillent. Ils ont des difficultés à évaluer la valeur des fonctionnalités qui n’ont pas un montant d’argent précis qui leur est alloué.
Les éléments du Coût de Retard (Cost of Delay – CoD)
Comment une organisation détermine-t-elle le coût de retarder un projet, ou le coût de ne pas faire le projet du tout, quand le résultat financier est indéterminé ? Et même s’ils peuvent déterminer ce résultat financier, comment choisissent-ils au final que faire ensuite ?
Dans Principles of Product Development Flow, Don Reinertsen affirme que le CoD peut être défini avec les trois paramètres suivants :
- Valeur business pour l’utilisateur
- Criticité temporelle
- Valeur de la réduction de risque et/ou de la création d’opportunité
Il définit que la somme des 3 paramètres donne le Coût de Retard (Cost of Delay – CoD).
Le travail pondéré le plus court en premier
Dans son livre, Reinertsen présente aussi un modèle qui permettra à votre organisation de peser l’importance de chaque nouveau projet et de prendre une décision informée sur quelle est la chose suivante la plus importante.
Il appelle ce modèle : le Travail Pondéré le Plus court en Premier (ou Weighted Shortest Job First – WSJF). Essentiellement, WSJF = CoD divisé par la taille du travail.
Voici un exemple de table que vous pouvez utiliser pour déterminer vos valeurs de WSJF par projet ou fonctionnalité. Vous évaluerez ainsi chaque élément par rapport aux autres de la liste en utilisant les trois paramètres qui composent le CoD.
|
1 |
2 |
3 |
4 |
5 |
|
|
Fonctionnalité (ou projet) |
Valeur Business pour l’Utilisateur |
Criticité Temporelle |
Valeur de réduction de risque ou création d’opportunité |
Taille du travail à faire |
WSJF (2+3+4)/5 |
Détermination de la valeur
Maintenant que nous avons une formule de base et le moyen de la visualiser :
- Comment déterminez-vous la valeur appropriée de chaque paramètre ?
- Quelle est l’unité de mesure ?
J’aime le faire de la même manière que pour les histoires d’utilisateur (User Stories). Je réunis les propriétaires de produit et quelques responsables techniques principaux autour d’une table et nous commencerons à assigner des points.
J’aime utiliser une Échelle de Fibonacci, en la limitant à 20 et prendre une colonne à la fois. Nous examinons la fonctionnalité et allouons une valeur business, puis une valeur pour la Criticité temporelle et enfin une valeur pour Risque et Opportunité.
Une fois que nous avons déterminé ces valeurs, nous pouvons calculer un total de point pour le CoD, le diviser par la taille du travail à réaliser et obtenir notre valeur de WSJF. Avec celle-ci, nous avons réussi à déterminer la prochaine chose la plus importante à faire.
Très souvent, quand je présente ce modèle à mes clients, ils résistent et me disent qu’il leur semble donner des décisions aléatoires. Cependant, gardons à l’esprit que l’importance de chaque paramètre peut être subjective. La valeur réelle du CoD peut ne pas être mathématiquement quantifiable, et c’est OK.
Compréhension partagée
CoD et WSJF sont seulement des outils pour permettre de faire la priorisation. 
Il n’importe pas vraiment que nous allouions des valeurs avec notre connaissance collective, ce qui importe est la comparaison relative d’une chose avec une autre. L’application de cette technique permet au processus décisionnel d’être influencé par l’équipe. Elle ouvre une conversation sur pourquoi une fonctionnalité est valorisé avec des 20 et une autre avec des 5.
Ce qui importe vraiment est que chacun dans l’équipe soit d’accord sur ce qui est dans la liste et que tous aient une compréhension des valeurs attribuées. Mon expérience est que quand vous avez une équipe de personnes qui sont toutes de l’industrie et focalisées sur le meilleur pour la société, la décision prise sera plus que probablement la décision la meilleure pour l’organisation.
Ce modèle est seulement une façon de réaliser la priorisation, mais il y en a d’autres.
Parfois, particulièrement dans les startups, je vois les gens utiliser des rapports de Gartner ou considérer leur part de marché pour prendre des décisions business. Souvent, ils agissent par instinct et utilisent des chiffres confus pour justifier les investissements.
Le modèle CoD/WSJF est une excellente façon de purger et prioriser un arriéré de produit en l’absence de valeur financière.
Aussi, si vous avez des difficultés à mesurer la valeur, je reprends les paroles de Reinertsen:
“…si vous allez évaluer quantitativement une chose, évaluez également quantitativement le coût de retard à ne pas l’avoir.”
SCRUM ne s’applique pas seulement dans le développement de logiciels, bien au contraire
Scrum est une méthode universelle
Il y a quelques années, Craig Brown qui anime le Melbourne Scrum User group a commencé à prôner que Scrum est une méthode universelle et non pas réservée uniquement aux projets de développement de logiciels.
Voici ce que je retiens encore aujourd’hui de la description qu’il donnait de Scrum et qui s’applique à tout projet :
1. Commencez avec un objectif. Puis, décomposez-le en étapes incrémentales.
2. Discutez des étapes avec l’équipe qui doit livrer la solution.
3. Définissez des périodes de temps standards (timebox) pour les itérations. Faites de votre mieux pour livrer quelque chose de valeur, utilisable et utile à chaque itération.
4. L’équipe prend ses « ordres » (ses priorités) du client au début de chaque itération et fait un rapport sur ce qui a été « fait » (totalement achevé) à la fin de chaque itération (Sprint Review).
5. L’équipe doit mettre du temps de coté au début de chaque itération pour planifier son travail (Sprint Planning).
6. L’équipe doit aussi mettre du temps de coté pour une brève session d’échanges chaque jour entre ses membres sur les progrès réalisés et les problèmes rencontrés (Daily Scrum).
7. L’équipe doit s’engager à l’amélioration continue et mettre du temps de coté à chaque itération pour réfléchir à ce qui est bien allé ou pas et identifier où l’on peut s’améliorer et comment (Sprint Retrospective).
8. La planification, la revue et les sessions de réflexion et réunions d’équipe quotidiennes doivent avoir lieu à des heures régulières pour aider l’équipe à trouver et tenir un rythme.
Mai 2018 – articles les plus lus par les lecteurs du blog DantotsuPM
Management de projet hybride, nouveaux guides du PMI, outils Microsoft… mais aussi se comporter en adulte furent les billet qui retinrent votre attention en Mai 2018 et que vous aimerez peut-être relire ou découvrir en cette période estivale plus calme.
« une main de fer dans un gant de velours » avec les approches prédictives et Agile selon Christine Rieu, Sylvain Gautier et Marc Burlereaux
Cet article publié il y a plusieurs années et repris à l’occasion du forum des régions PMI France 2018 a connu un regain de succès. C’est très mérité car les auteurs, Christine Rieu, Sylvain Gautier et Marc Burlereaux, avaient pris le temps de partager avec nous leur expérience de l’agilité et premières idées pour adopter une approche plus hybride.
L’approche Agile dans les projets de développement de nouveaux produits permet d’assurer plus de souplesse dans la conception itérative, plus de légèreté dans la documentation et dans la formalisation, plus d’interactivité et d’efficacité dans la conduite de réunions, et surtout plus d’implication du client tout au long du projet. En couplant une approche Lean à ces méthodes Agiles, nous supprimons en plus toutes les étapes inutiles sans valeur ajoutée pour limiter les gaspillages et maximiser ainsi la valeur attendue du produit.
Une liste de 25 principes de comportement adulte par John Perry Barlow
Quand il avait 30 ans, le fondateur de l’Electronic Frontier Foundation (et parfois parolier de Grateful Dead) a rédigé une liste de ce qu’il a appelé « les Principes de Comportement Adulte ». Lesquels 5 ou 6 éliriez-vous dans cette liste pour votre propre éthique ? J’aime beaucoup 2,3,4,5,6,7,8…
…impossible de choisir.
Microsoft Planner ou Microsoft Project: Lequel utiliser pour manager vos projets ?
À ce jour, vous êtes probablement déjà familiers de Microsoft Project. Sorti en 1990, Microsoft Project est devenu l’application par défaut pour les chefs de projets. Microsoft Planner est une solution de gestion de projet plus récente qui a été publiée en 2016 dans le cadre d’Office 365. Les deux applications nous laissent créer des plans, organiser et confier des tâches, partager des dossiers, communiquer avec des collègues et obtenir des mises à jour sur le progrès de notre équipe.
Alors, quelle solution devrions-nous utiliser ?
le combiné « Guide PMBOK® + Guide pratique des méthodes Agiles » du Project Management Institute est disponible en français
Afin de soutenir l’éventail de plus en plus large des approches de réalisation de projets, PMI propose un PMBOK® Guide – Sixième édition accompagné du nouveau Guide de pratiques Agiles.
En mode ‘Ciel, mon outil PPM !’, 6 points-clé à ne pas manquer pour réussir le choix de sa solution de pilotage des projets !
Quand le sujet de choisir son outil PPM devient un vrai casse-tête, que vous vous perdez devant la pléthore d’offres et que vous ne savez plus vraiment comment faire le bon choix…
Pas de panique, détendez-vous ! On vous dit tout !
DantotsuPM.com 
