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.
Partenaire de DantotsuPM
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.
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Un aperçu de la méthode est téléchargeable en ligne
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.
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
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
CertYou est partenaire de DantotsuPM
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 :
Carte d’Empathie dans un cadre, par Paul Boag (Boagworld.com)
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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 ?
Relire la Saga
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.
Yohann Romand
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…
Amélioration continue…
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
Demandez une démonstration 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
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Livre sur Amazon (Gratuit en version PDF sur le site PMI pour ses adhérents)
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.
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.
Méta Projets Management est partenaire de DantotsuPM
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Relisez le billet sur Eisenhower et John Adair
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.
Petit à petit, ces tâches cumulent des bénéfices.
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 !
CSP est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Livre sur Amazon
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 ?
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.”
SMPP est Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
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…
À 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.
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 !
SMPP est Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Je vous ai déjà parlé plusieurs fois de la Théorie des Contraintes et de la chaine critique.
Voici une vidéo du Dr Lisa Lang qui peut tenir lieu d’introduction
Je n’ai aucun retour d’expérience personnel à partager avec vous mais certains d’entre vous, chers lecteurs, ont certainement déjà appliqué cette approche que je trouve fort pertinente. L’objectif est d’optimiser l’utilisation des ressources les plus critiques et souvent les plus rares sur un ou plusieurs projets qui s’exécuteraient en parallèle.
Comment commencez-vous un projet en utilisant la méthode de gestion de projet PRINCE2 ? Mark Sutton, le manager et formateur de changement, considère ces étapes :
Mark Sutton
La mise en route d’un projet – selon PRINCE2 – est déclenchée par un mandat : une raison de faire quelque chose ou, autrement dit, une justification d’affaires.
En essence, il s’agit de répondre à un problème perçu, un dilemme ou une opportunité dans ou à l’extérieur d’une organisation; cela signifie probablement que l’organisation se déplace dans une nouvelle direction stratégique et cela exige du changement.
Vous pouvez être chanceux et recevoir un mandat bien articulé; cependant, vous pourriez l’être moins et devoir travailler un peu pour comprendre le challenge qui vous est donné. Par exemple, quand je travaillais avec la poste et le service de distribution des colis postaux du Royaume Uni, le Royal Mail, nous étions chargés de l’automatisation du processus de triage. Comme la solution n’était pas immédiatement claire, nous avons passé en revue le marché lors d’un exercice de faisabilité technique pour évaluer les solutions possibles. Le résultat de l’exercice de faisabilité est devenu le mandat de projet.
En utilisant l’approche de PRINCE2, vous pouvez rapidement passer en revue le challenge et acquérir un sentiment de ce que le projet comprendra. Cela vous aide à comprendre si cela vaut vraiment la peine d’y investir. Ce pourrait ne pas être le cas et, dans le contexte de votre projet potentiel, vous voulez être capables “d’échouer vite”.
QRP International est partenaire de DantotsuPM
En commençant un projet, il y a plusieurs choses que vous devriez considérer selon la méthode PRINCE2 :
Accordez-vous sur qui est responsable du projet s’il est lancé, c’est-à-dire le cadre exécutif. Cette personne expérimentée va probablement amorcer le travail d’investigation nécessaire avec le soutien de chef de projet.
Thèmes Prince2
Demandez : Avons-nous fait ce type de chose auparavant ? Quelles leçons utiles pouvons-nous en apprendre sur ce qui est allé bien ou pas ? Vous trouverez cette connaissance dans l’organisation ou bien vous devrez chercher ailleurs si vous n’avez pas une telle expérience en interne à exploiter.
Rôles et responsabilités : Si vous progressez sur l’idée, quelle équipe, rôles et responsabilités devez-vous avoir en place ? Cela pourrait signifier passer en revue les gens avec lesquels vous avez travaillés avec auparavant et choisir qui impliquer, ou non. L’identité de certains membres d’équipe peut rester floue (par exemple les partenaires qui rejoindront l’équipe après un effort de recrutement), donc cela peut comprendre lister en gros les rôles et compétences exigés.
Combien de temps investirez-vous dans le processus de planification et d’introduction, quelle est l’équipe impliquée et que feront-ils ?
Vous devez penser à ce que le projet va construire et comment engager la discussion avec ceux qui l’utiliseront. Quelles améliorations/bénéfices apportera-t-il à l’organisation et quel sera le retour sur investissement ?
Avec tous les éléments ci-dessus, vous devriez maintenant avoir toute les informations pour permettre une décision quant à si le projet devrait avancer à la phase de planification et d’introduction.
Partenaire de DantotsuPM
Le cas d’affaire
Celui ou celle qui a la responsabilité complète du projet voudra s’assurer que l’investissement business continue à rester justifié. Ce qui signifie contrôler l’évolution du mandat de projet vers le cas d’affaire de haut niveau puis dans le cas d’affaires détaillé lui-même (confirmé à la fin de la planification et du travail d’introduction qui viennent ensuite). Cependant, le cas d’affaire est un document dynamique mis à jour au moins à la fin de chaque étape du projet et servant toujours comme point de référence.
Pour que le projet progresse, vous devez garantir le financement du travail en identifiant une équipe et écrivant un plan de démarrage. Financer le démarrage de projet nécessite que le conseil de projet approuve le budget, en se basant sur le dossier de projet : ce que vous construisez, le cas d’affaire de haut niveau plus les rôles et responsabilités.
En général, en commençant un projet, vous devez clarifier les besoins de l’organisation, ce qu’elle attend que vous fassiez et confirmer qu’il y a une proposition raisonnable qui mérite un projet. Si vous travaillez dans le contexte d’un programme, cette analyse a probablement déjà été faite.
Souvenez-vous, au début même du processus de commencer un projet, quelqu’un pourrait avoir seulement le début d’une idée qu’il y a quelque chose qui fait sens pour l’organisation; une fois que vous entrez dans le vif du projet, les choses deviennent habituellement plus claires.
partagez ce billet avec vos amis, collègues et relations professionnelles
La RAM, Responsibility Assignment Matrix, ou Matrice d’Affectation des Responsabilités sert à documenter les rôles et responsabilités de chacun dans le projet.
Cet outil, qui prend la forme d’un tableau (qui croise la structure de décomposition du projet/WBS et les ressources de l’organisation) permet au chef de projet de lister les participants au projet ainsi que leur(s) responsabilité(s).
Le RACI est l’exemple de RAM le plus utilisé, a pour point de départ le croisement de la structure de découpage de projet ou SDP/WBS avec les ressources du projet.
« Qu’est-ce qui différencie les projets des activités régulières ? »: Lors de votre prochain entretien pour un job de chef de projet, cette question pourrait fort bien vous être posée.
Une lettre d’un chercheur en physique au Laboratoire Lawrence Livermore du nom de Tom Hirshfield. Tom y partageait quelques principes de base qu’il avait personnellement trouvés utile dans son travail et à utiliser comme bon vous semble dans le votre.
Voici quelques-unes des étapes sur lesquelles je plancherais pour préparer un plan à 90 jours que je pourrais proposer à mon futur employeur dès les premiers entretiens…
partagez ce billet avec vos amis, collègues et relations professionnelles
Une des choses les plus importantes à comprendre dans le monde du business (et dans la vie en général) est le concept de complexité. Tandis que nous utilisons les mots compliqué et complexe presque de manière interchangeable dans le parler quotidien, ils signifient en réalité des choses très différentes. Explorons mon modèle favori sur la complexité : Cynefin.
Il existe un certain nombre d’articles et vidéos d’introduction à Cynefin, y compris celle de Dave Snowden, mais certains ne sont pas toujours très accessibles.
Cynefin parle de quatre types différents de problèmes ou domaines. Évident, Compliqué, Complexe et Chaotique. Nous aborderons ces premiers et couvrirons à la fin le Désordre.
Cynefin est une façon d’appréhender de quel type est un problème est et propose une stratégie de haut niveau pour résoudre ces différents types de problèmes.
1. Évident
L’analogie de jeu pour Évident est le Tic-Tac-Toe, aussi appelé « morpion ». Comme dans le Tic-Tac-Toe, les problèmes Évidents ont un lien de cause à effet clair et prévisible.
La stratégie de haut niveau pour résoudre des problèmes Évidents est « Observer – Catégoriser – Répondre ». Observer n’est rien de plus complexe dans ce cas que regarder la grille. Catégoriser les moyens que nous avons de réduire toutes les combinaisons possibles en sous-ensemble beaucoup plus petit, gérable. Et Répondre faire un déplacement. Tic-Tac-Toe a 255,168 parties possibles, mais nous avons besoin de connaitre seulement quelques règles pour jouer la meilleure partie possible. Prenez le pion de départ, il devrait être placé dans un angle, n’importe quel angle fera l’affaire.
Nous répondons aux problèmes Évidents en choisissant la Meilleure Pratique appropriée.
Nous avons regardé toutes les options possibles et calculé la meilleure voie. Ils sont appelés « Best », parce qu’il y a toujours exactement une meilleure réponse.
Le problème évident avec les problèmes évidents est que peu d’entre ceux restent sans réponse. C’est la substance qui est facilement automatisée. Les ordinateurs sont extrêmement précieux pour ce type de travail.
2. Compliqué
Maintenant, le Tic-Tac-Toe (les Morpions) est un jeu très ennuyeux précisément parce que nous l’avons calculé. Après, les meilleures pratiques vous feront jouer un jeu parfait. Si les deux joueurs jouent un jeu parfait il est un dessiné.
Les échecs sont très différents. Et notre stratégie de haut niveau pour des problèmes Évidents ne nous aidera pas le jeu d’échecs. Quelques mouvements dans un jeu d’échecs et le conseil sont dans une position vous ne l’avez jamais vu dans auparavant. Et plus important encore une différence minuscule dans le conseil fait une différence massive dans le jeu.
Dans des problèmes compliqués le rapport entre la cause et l’effet est prévisible, mais (très durement prévoir. Des problèmes compliqués sont le domaine d’expert, qui est meilleur capable de prévoir ce qui va probablement arriver. Qui est exactement quels joueurs d’échecs supérieurs font. Ils doivent prévoir ce que les mouvements probables de leurs adversaires vont être. Les experts peuvent simultanément considérer des options plus possibles, mais le réduire aussi à un jeu plus petit des scénarios qui exigent plus d’analyse.
Donc la stratégie devient le Observer – Analyser – Répondre. Et parce que c’est la figure impossible de si un mouvement est le meilleur mouvement (sauf la défaite évidemment) il n’y a aucune pratique la meilleure dans le domaine compliqué.
Mais il y a de bonnes pratiques. Les pratiques que l’on considère utile dans de certains contextes. Dans des échecs un exemple est la valeur de vos pièces. Chaque morceau dans des échecs fait associer une valeur avec cela. Et vous voulez toujours la valeur totale de vos pièces pour être plus haut que vos adversaires. À moins que vous ne vouliez que, parce que vous vouliez sacrifier un morceau pour la position de conseil.
3. Complexe
Les problèmes complexes sont à nouveau complètement différents. Ce qui les met à part est que le rapport entre la cause et l’effet est seulement évident de manière rétrospective. La métaphore de jeu pour la complexité est le poker. À la différence des échecs, qui sont un jeu de prévision, le poker est le jeu de l’étude. Apprendre quelles cartes vos adversaires ont et comment leurs mains se mesurent à la vôtre. Et la stratégie de haut niveau des échecs ne fonctionne pas pour le poker.
Si vous jouez ma version favorite de poker, le Texas Hold’em, vous pouvez regarder vos propres cartes jusqu’à en perdre le souffle, mais la seule chose que vous allez apprendre est que vos adversaires n’ont pas exactement les mêmes cartes que vous. Donc Sentir – Analyser – Répondre est éliminé comme façon de traiter la complexité.
Ce dont nous avons besoin à la place est Investiguer –Sentir – Répondre. Une investigation est une expérience sans risque. Selon le résultat de cette expérience (Sentir) nous répondons en amplifiant les bonnes et/ou réduisant les mauvaises (Répondre).
De nouveau, prenant l’exemple du poker, l’investigation peut prendre la forme d’une mise. Si vous déposer une mise vous forcez des adversaires à y répondre, en se couchant, répondant ou surenchérissant. Cela peut vous donner de l’information sur leur main. Mais d’autres investigations peuvent être d’attirer l’attention des adversaires, sentir peut être seulement regarder leurs comportements.
Donc la chose la plus importante de la Complexité est qu’il n’y a aucune façon d’apprendre (et ainsi résoudre le problème) sans faire. Réfléchir ne va pas résoudre le problème. Dans les problèmes Complexes, nos pratiques se développent toujours en se basant sur ce que nous apprenons. Dans le poker, même si nous jouerions une partie avec exactement les mêmes joueurs et exactement les mêmes cartes exactes, la partie serait différente. Parce que nous avons appris des choses pas seulement sur le jeu, mais aussi sur nos adversaires.
4. Chaos
Le chaos arrive quand il n’y a aucun rapport entre la cause et l’effet ou qu’ils changent très rapidement. Dans ce cas il n’y a aucune raison de réaliser des investigations parce qu’aucune étude ne nous aidera à nous améliorer.
L’analogie de jeu est ici le jeu d’enfants. Quelqu’un qui a déjà joué avec des gosses sait que les règles changent continuellement. Et il n’y a aucune raison d’essayer d’apprendre les règles avant le départ du jeu. Vous devez entrer et jouer avec eux (Agir), tout en vous assurant de l’amusement (Sentir) et en changeant en conséquence (Répondre).
Mais le plus souvent nous terminons dans le Chaos à cause d’une petite crise. Quand cela arrive nous devons très rapidement stabiliser la situation et ressortir du Chaos. Cela arrive tout le temps dans le business, où nous nous reposons fréquemment sur des leaders héroïques et des équipes spéciales pour nous sortir des problèmes.
Les pratiques sont ici Nouvelles.
Désordre
Le désordre n’est pas un domaine séparé, mais signifie au lieu de cela que nous utilisons le jeu de stratégies avec lequel nous sommes à l’aise au lieu de celles appropriées au problème à résoudre.
Et la malheureuse réalité consiste en ce que la plupart des personnes passent ici la plus grande partie de leur temps.
Je ne plaisante ni n’exagère pas quand je dis que comprendre Cynefin a changé ma vie.
Chaque fois que je me trouve (ou les gens autour de moi) à passer trop de temps à réfléchir, mon premier instinct est de prendre du recul pour m’assurer que le problème à traiter est Compliqué. Quand les organisations continuent à insister sur les Meilleures Pratiques, je vérifie d’abord si le problème est à portée de main en fait Évident. S’il est Compliqué (ce qui est très probable), nous devrions regarder une myriade de bonnes pratiques et calculer quelles pratiques sont applicables dans quelles circonstances.
Mais la leçon la plus importante est que bon nombre de nos circonstances sont complexes. Et ainsi en soi imprévisibles. Et aucune quantité de réflexion ne va les résoudre.
CSP est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous vous souvenez surement de l’article précédent (Relire l’article : ici), alors vous êtes prêts pour vous lancer en Mode Projet dans l’acquisition d’un SIRH !
Mais COMMENT et QUEL SIRH choisir ?
Les tentations sont nombreuses n’est-ce pas ?
Devant la multitude des acteurs sur le marché des SIRH, il est important de se poser les bonnes questions et vous laisser guider dans le choix.
TENTATION 1 : SaaS ou… Licence ?
Sans doute la première des tentations et questions que vous devez avoir, quelle configuration est adaptée ?
La différence entre Licence et Mode SaaS, vous la connaissez ?
On vous en touche quelques mots…La Licence est une acquisition du logiciel associée à une gestion interne des infrastructures (hébergement sur vos serveurs…).
Le mode SAAS (Software As A Service) est quant à lui, un abonnement avec une logique d’externalisation et de mutualisation de la gestion des infrastructures (serveur, réseau…).
Soyez vigilants toutefois, sous Licence, la mise à jour de la solution est souvent payante et non automatique ! Ne vous laissez pas surprendre donc, la mise à jour des règles légales (taux…) peut être en effet à votre charge et une externalisation de tout ou partie de la gestion de votre paie n’est pas possible.
Le mode SaaS séduit, grâce à la modernisation des solutions proposées en mode Cloud, de plus en plus d’éditeurs ne font que du SaaS ! et pour cause, en mode SAAS, vous n’avez plus à vous occuper de la mise à jour des données légales, les évolutions de version sont souvent incluses et l’éditeur est garant de la sécurité des données, notamment avec la nouvelle norme RGPD… tentant non ?
TENTATION 2 : INTER ou EXTER…-nationalisation de la paie ?
Souhaitez-vous garder la gestion de la paie, souvent complexe et chronophage, en interne ? Ou bien vous soumettre totalement à …un expert? … Attrayant n’est-ce pas ?
Évidemment vous l’aurez compris, pour les éditeurs ou intégrateurs qui proposent une acquisition de la solution sous Licence, l’externalisation n’est pas possible !
Le mode SAAS offre du choix :
En effet diverses prestations peuvent être proposées : Des éditeurs ne proposent que 2 modes : internalisation totale ou externalisation totale sans accès au logiciel !!!
D’autres éditeurs ont fait le choix d’une granularité très fine avec une sélection du service à la tâche de qui fait quoi !
Alors, prêt à tout …confier ?
TENTATION 3 : Serez-vous en mode …EXPERT ou COLLABORATIF ?
Fervent défenseur d’une gestion des Ressources Humaines décentralisée, d’une implication des collaborateurs dans leur développement professionnel et des managers dans la gestion de leurs équipes ?
Alors optez pour une solution collaborative avec un portail partagé : saisie des demandes de congés, demandes de formation ou compléter ses entretiens !
Si vous êtes dans le cas d’une gestion du logiciel par le service RH seulement, alors préférez une solution en mode Expert.
TENTATION 4 : ERP ou logiciels experts interfacés ?
Si gérer les interfaces et les connexions entre logiciels ne vous attirent pas, laissez-vous séduire par un ERP (progiciel de gestion intégrée) :
Il vous proposera l’ensemble des modules de gestion des Ressources Humaines (Paie, gestion des temps et absences, formation, entretien, GPEC…) !
Mais attention, la maîtrise et la performance de la solution sur l’ensemble des domaines RH n’est pas toujours garantie !
Par ailleurs, si vous veniez à ne pas être satisfait de la partie paie et vous prend l’envie de changer, c’est alors l’intégralité des modules RH qui devront être changés !
Plus sur une envie de spécialistes dédiés à chacune des thématiques RH ? Comme on vous comprend… c’est du pur délice.
La tendance aujourd’hui est de choisir des éditeurs spécifiques de chacun des domaines (recrutement, paie, GTA, formation…) et de les interfacer !
Quelques inconvénients à connaitre : Le coût additionnel est souvent plus cher, les hébergements sont démultipliés et la transmission des données entre éditeurs peut être complexe à gérer !
TENTATION 5 : toute taille, tout secteur d’activité ?
Dernière tentation et non des moindres…Certains éditeurs proposent des solutions diverses couvrant toute taille d’entreprise et tout secteur d’activité…
D’autres se sont spécialisés et ont développé leurs applications intégrant les spécificités des domaines d’activité (ex : gestion des extras pour l’hôtellerie, gestion des contrats particuliers type pigistes, journalistes…).
A vous de voir si…votre entreprise est plutôt classique ? ou revêt des spécificités en gestion des Ressources Humaines ? Soyez vigilant à ne pas vous faire aguicher !
Pour conclure sur toutes ces tentations, le choix de son SIRH ne se résume pas finalement à un jeu de hasard mais bel et bien à un ensemble de critères de sélection qui doivent être tous… murement réfléchis.
Vous l’aurez compris, pour un tel projet, le pilotage en mode Projet est de mise (cadrage, planification, plan de charge…) !
Et si vous êtes à la recherche d’un pilotage simple et efficace, le Cabinet 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 !
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous avez entendu vos amis chanter les louanges d’Agile. Vos copains chefs de projet deviennent des scrum masters. Vous entendez combien c’est formidable. Tous les gamins dans le coup le font et vous êtes un peu jaloux. Vous vous sentez exclu. Vous voulez voir l’objet de toute cette agitation.
Bonnes nouvelles ! Il existe des pratiques Agiles que vous pouvez utiliser même dans votre monde prédictif en cascade. Vous obtiendrez les bénéfices d’une communication accrue, de la collaboration avec le client et de l’amélioration continue. Et vous aurez une opportunité de présenter quelques pratiques Agiles à votre équipe. Sans devoir vous coller à la transition de l’organisation toute entière vers Agile.
AVERTISSEMENT : que faire avant que vous n’adoptiez ces pratiques Agiles
N’adoptez pas de pratiques Agiles simplement pour suivre les foules.
Comprenez les bénéfices que vous tirerez à incorporer des pratiques Agiles. Vous économiserez du temps et de l’argent en obtenant des réactions des clients et en livrant le bon produit. Vous travaillerez plus intelligemment avec une communication accrue et transverse dans l’équipe et des pratiques de travail améliorées.
Discutez avec votre équipe et obtenez leur adhésion. Le changement sera un effort d’équipe et vous aurez besoin de leur collaboration et coopération. L’équipe entière doit être à bord. Vous ne pouvez pas réussir seul.
Partagez vos idées avec l’équipe sur pourquoi vous voulez le faire. Découvrez les idées et préoccupations de vos coéquipiers. Assurez-vous qu’ils sont ouverts à faire un essai. Vous devrez vous lancer avec leur appui, parce qu’ils font aussi partie du jeu.
Voici 3 pratiques Agiles que vous pouvez déjà commencer à utiliser:
1. Standup Quotidien
Bénéfices : transparence et communication accrues dans l’équipe.
Votre équipe aura une plus grande compréhension de la progression et des défis. Le chef de projet peut « mener » si nécessaire, mais les équipes Agiles s’auto-organisent et peuvent le faire elles-mêmes si le chef de projet n’est pas là.
Comment le faire : c’est une réunion très courte (15 minutes ou moins) qui donne chaque jour une occasion à l’équipe de faire un point et partager l’information.
Chaque membre d’équipe répond brièvement à ces trois questions :
Qu’avez-vous fait hier ?
Sur quoi travaillez-vous aujourd’hui ?
Y-a-t-il des obstacles vous empêchant de faire votre travail ?
Dans le Scrum traditionnel, le scrum master élimine les points de blocage, mais le chef de projet peut aussi le faire.
Avertissement : ce n’est pas une réunion de statut d’avancement de 30 minutes. Ce n’est pas une longue discussion sur les détails. Cela devrait plutôt être très court : 15 minutes ou moins. C’est un rendez-vous pour votre équipe chaque jour pour rester à niveau. Si l’équipe doit discuter de plus de détails, faites-le après le stand up.
Un de mes amis a suggéré à son chef qu’ils s’y essaient. Ils avaient des très longues réunions de statut de projet. Son patron a accepté et aimé l’idée. Mais au lieu que ce soient les membres de l’équipe qui aient une réunion quotidienne rapide, son chef la dirige. Pis encore, le stand up s’est métamorphosé en réunion de statut prolongée tous les jours : une situation pire qu’avant. Évitez la tentation de faire traîner le stand up. Tenez l’agenda et le rythme et gardez les longues conversations pour après le stand up.
2. La Rétrospective
Bénéfices : amélioration continue.
Votre équipe identifiera des façons de s’améliorer pendant le projet, plutôt que d’attendre jusqu’à ce que le projet soit fini. Vous y gagnerez les bénéfices d’améliorations continues tout au long du projet.
Comment le faire : à divers moments pendant le projet, l’équipe évalue son efficacité.
Livre sur Amazon
Il y a 3 questions clefs à poser :
Qu’est-ce qui a fonctionné bien pour nous ?
Qu’est-ce qui n’a pas bien marché ?
Que pouvons-nous faire différemment pour nous améliorer ?
Choisissez divers moments pendant le projet pour mettre en œuvre cette pratique Agile. Une fois que vous avez fait l’exercice et identifié des choses que vous pouvez améliorer, choisissez-en une ou deux à cibler les premières. Incorporez ces changements et voyez comment ça va. Répétez ensuite ce processus pendant le projet.
Votre équipe peut incorporer des améliorations tandis que le projet est toujours en voie de réalisation, plutôt qu’attendre jusqu’à ce que le projet soit fini.
Notez : Il doit y avoir un environnement de confiance et de soutien entre les membres de l’équipe. Ne critiquez personne pour des suggestions faites. Ne blâmez pas de membres pour des fautes, mais identifiez plutôt des façons de vous améliorer. Soyez ouvert à considérer les challenges comme des opportunités.
3. Démonstrations de logiciel au client
Bénéfices : transparence et collaboration avec le client.
Les clients bénéficient de voir le produit en l’état et en partageant leurs réactions. L’équipe obtient l’avantage de retours des client sur n’importe quels ajustements nécessaires.
Comment le faire : Démontrez un logiciel qui fonctionne au client à des points appropriés en cours de développement. N’attendez pas jusqu’à ce que tout ce soit prêt pour les tests d’acceptation de l’utilisateur final.
Ce n’est pas une présentation PowerPoint. Vous montrez le logiciel réel. Ne cherchez pas de tape à l’œil ni perfection. Votre but est de montrer au client comment le produit progresse et d’obtenir des réactions. Vous ne devez pas louer une énorme salle de conférences et faire des PowerPoint tapageur. Vous ne montrez pas de produit fini pour l’instant.
Gérez les attentes du client sur ce que vous montrez. Vous ne voulez pas les étonner s’ils s’attendaient à quelque chose d’autre. Assurez-vous qu’ils sont conscients que c’est un premier jet et pas le produit fini. Expliquez pourquoi vous le faites et ce que vous espérez y gagner.
CertYou est partenaire de DantotsuPM
C’est un Voyage
Adoptez un esprit de collaboration, de communication et d’amélioration continue. Faites-le avec respect pour tous vos membres d’équipe pendant que vous adoptez de nouvelles pratiques.
Soyez patient avec eux. Vous n’atteindrez pas tout de suite la perfection. Mais vous en bénéficierez et l’aimerez probablement, aussi.
Maintenant que nous avons vu ces 3 pratiques Agiles, vous pouvez probablement voir comment les utiliser même si vous ne vous lancez pas à fond dans Agile.
Il n’y a désormais plus aucune raison de vous sentir exclu. La prochaine fois que vos amis scrum masters parleront Agile, vous pourrez vous joindre à eux.
Dites-leur les façons dont votre équipe s’en sert pour s’améliorer et combien vos clients en sont heureux.
Et ces autres amis qui ne l’ont pas encore essayé ? Partager votre amitié en partageant cette information avec eux !
partagez ce billet avec vos amis, collègues et relations professionnelles
Quelle solution choisir entre MS Project et MS Planner ?
Ceci est une question que l’on peut légitimement se poser quand on lit les commentaires et annonces récentes sur ces applications. Voici un article complet en anglais et consultable sur le site de Microsoft qui traite justement de ce sujet !
À 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 ?
Voici un comparatif pour nous permettre de décider laquelle convient le mieux à nos besoins. La table de comparaison ci-dessous récapitule les résultats en un coup d’œil, mais les choses sont ensuite explicitées dans l’article détaillé.
Microsoft Planner
Page dédiée sur le site Microsoft France
Microsoft Planner permet aux équipes de créer des plans; organiser, assigner et collaborer aux tâches; délais d’ensemble; chat avec les collègues pour rester à jour sur le progrès; et téléchargement et partage de documents. Vous pouvez suivre à la trace le progrès de votre équipe dans un tableau de bord visuel et vous obtiendrez des mises à jour sur les nouveaux développements via des notifications par courrier électronique. Chaque plan que vous créez est automatiquement associé à un nouveau groupe Office 365, que vous pouvez définir comme privé ou public.
Microsoft Project Online
Partenaire de DantotsuPM
De prime abord, Microsoft Project peut sembler plutôt intimidant !
Mais, Microsoft Project propose de nombreux modèles que vous pouvez regarder et utiliser comme point de départ quand vous créez un nouveau projet. Vous pouvez les modifier pour répondre à vos besoins spécifiques et les sauver pour de futurs projets similaires; sinon, vous pouvez aussi commencer par un modèle vierge.
Ceci rend beaucoup plus facile de débuter un projet, car vous ne devez pas tout développer à partir de zéro. A l’inverse, Microsoft Planner n’offre pas de modèles prédéfinis.
Microsoft Planner contre Microsoft Project: Quelle est la solution pour vous ?
Essayez les deux pour forger votre propre décision
Microsoft Planner est sans aucun doute une application utile pour créer et suivre à la trace des plans de projets simples, mais ses limitations deviennent claires si vous voulez avoir un plus grand contrôle de vos projets. Avec une plus large gamme de support et de fonctionnalités, Microsoft Project est la solution idéale pour la planification de projet d’entreprise.
partagez ce billet avec vos amis, collègues et relations professionnelles
Curieusement, l’auteur reste très dichotomique et ne considère pas dans ce billet une approche hybride entre les deux mondes adaptatif et prédictif mais son retour sur la genèse de la méthode Waterfall me parait intéressant à partager avec vous.
What Does ‘Waterfall’ Really Mean? How Do People Use That Word?
Y avez-vous jamais réfléchi ? Cette expression est souvent utilisée en comparaison de ‘Agile’ mais les gens savent-ils ce qu’ils font quand ils comparent ‘Agile’ à ‘en cascade’ ? Je pense que le mot ‘Waterfall’ est un des mots les plus abusés dans la langue anglaise (et le mot ‘Agile’ n’arrive pas loin derrière).
Quand les gens parlent de ‘Agile’ et ‘en cascade’, il semble qu’ils comparent deux méthodologies très spécifiques et bien définies qui sont les opposés binaires et mutuellement exclusifs l’un de l’autre. Cependant, quand vous fouillez dans ce que signifient vraiment les mots ‘Waterfall’ et ’Agile’, vous découvrez vite que c’est une comparaison très imprécise et prône à erreurs.
Que signifie vraiment ‘en cascade’ dans le management de projet ?
À proprement parler, le mot ‘ Waterfall ‘ a été à l’origine défini en 1970 par docteur Winston Royce dans son papier très célèbre :
Il a décrit un modèle qui consiste en ordonnancer un projet en phases où les livrables d’une phase coulent dans la phase suivante et qui donne quelque chose comme ceci :
Il l’a appelé ‘en cascade’ parce que les résultats d’une phase s’écoulent naturellement dans la phase suivante comme l’eau dans une ‘cascade’.
A quoi ressemblait la Vie avant ‘en cascade’ ?
Pour mieux comprendre, il est utile de voir à quoi ressemblait la vie avant ‘en cascade’ et quels problèmes cette méthode essayait de résoudre. Ce qui a précédé ‘en cascade’ était beaucoup d’efforts de développement mal organisés avec peu ou pas de structure, discipline et planification. Certains des problèmes principaux avec ces approches étaient :
Comme les projets grossissaient en termes de portée et de complexité avec de plus grands nombres de développeurs, il est vite devenu apparent qu’une approche plus planifiée et structurée était essentielle pour coordonner le travail de grosses équipes de développement
L’autre problème principal était une prévisibilité très limitée tant sur les dépenses que les délais des projets de développement informatique. Il y avait de fréquents en très importants dépassements de coûts et de délais et les commanditaires ont exigé un certain niveau de prévisibilité.
Pour ces raisons, quand l’approche ‘en cascade’ a été définie à l’origine, c’était une grande amélioration que de passer de pratiquement aucune méthodologie du tout à un processus très bien défini :
“Un plan d’ensemble” pour coordonner le travail de multiples développeurs ainsi que l’intégration de leur travail avec d’autres ressources essentielles en dehors des immédiates équipes de développement
Un mécanisme pour gagner un certain niveau de contrôle de la portée du logiciel (de son contenu ou périmètre) pour obtenir plus de prévisibilité des dépenses et des délais.
Beaucoup de personnes plus jeunes n’apprécient pas aujourd’hui cette historique et critiquent juste la méthode ‘en cascade’ comme étant mauvaise sans comprendre les problèmes qu’elle a été créée pour adresser.
relisez ce billet sur les bénéfices de ‘en cascade’
Quels étaient certains des problèmes avec l’approche de originale ‘en cascade’ ?
Comme dans beaucoup de choses, il y a un effet de « balancier » et, quand l’approche a été initialement mise en œuvre, il y avait le sorte d’une sur-correction dans de nombreux cas. Le balancier est passé dans beaucoup de projets de presque aucun contrôle ni discipline à un contrôle très rigide et très rigoureux. La pratique commune quand le processus ‘en cascade’ a été défini à l’origine en 1970 était un processus de documentation très intensif et un sur-contrôle où vous ne pouviez pas quitter une phase tant que toute la documentation exigée pour prouver que tout le travail demandé pour cette phase avait été achevé, passé en revue et approuvé.
C’était un processus très pénible et qui avait un certain nombre de problèmes que même le Dr. Royce a reconnus en 1970 quand il a défini le processus. Certains des problèmes les plus sérieux étaient :
L’utilisateur final du logiciel ne voyait pas normalement aucun logiciel avant que tout le développement et les tests ne soient complets et à ce moment-là, il était très difficile, sinon impossible, d’apporter quelques changements significatifs.
L’accent sur le contrôle du contenu rendait le processus très inflexible et résistant aux changements qui pourraient être nécessaires pour répondre aux besoins des utilisateurs et des objectifs business dans un environnement incertain.
En conséquence, il y a eu beaucoup de situations où le projet peut avoir respecté le coût et les délais, mais échoué à fournir un niveau suffisant de valeur business.
Un autre problème principal était que le lourd accent sur la documentation exigée pour les revues et les approbations rendait le processus tout entier bureaucratique et pas très efficace côté coûts.
Comment ‘en cascade’ s’est-elle développée pour Résoudre Ces Problèmes ?
Avant que Agile ne se répande, beaucoup de variations sur le modèle original ‘en cascade’ et d’autres modèles plus itératifs ont été développées et utilisées pour créer une approche plus adaptative et résoudre certains de ces problèmes. Un exemple était le Processus Unifié Rationnel (Rational Unified Process RUP) dont les origines peuvent être retracées jusqu’en 1996 et 1997. RUP a proposé une approche de développement itérative pour résoudre certains des problèmes de l’approche ‘en cascade’. RUP et les variations de RUP comme Enterprise Unified Process (EUP) sont devenus très populaires à la fin des années 1990 et au début d’années 2000.
En conséquence, si vous regardez ce que les gens ont fait en pratique pendant les 15 à 20 dernières années, il y a eu prolifération d’une large gamme de beaucoup de modèles différents (dont certains ont une ressemblance très limitée au modèle original ‘ Waterfall ‘ défini en 1970). Les gens les caractérisent toujours tous de ‘en cascade’ comme si c’était une méthodologie spécifique, unique et bien définie appelée ‘en cascade’ et ce n’est pas vraiment le cas. De la façon dont le mot ‘Waterfall’ est utilisé en pratique, il se réfère en réalité à une large gamme de méthodologies différentes.
Quelle est une façon plus précise de décrire ‘Agile’ versus ‘En cascade’ ?
Le dénominateur commun de toutes les méthodologies que les gens appellent ‘en cascade’ est qu’ils soulignent un certain niveau de planification en amont et de contrôle pour essayer de réaliser la prévisibilité sur le contenu du projet, des dépenses et des échéances. C’est pourquoi, je pense que « dirigé par un plan » est une description plus précise et objective de ce que les gens veulent vraiment dire quand ils disent ‘en cascade’.
Le mot ‘Agile’ est aussi utilisé de manière floue. Nous savons tous que ‘Agile’ n’est pas une méthodologie spécifique bien que beaucoup de personnes assimilent ‘Agile’ avec Scrum :
Scrum n’est pas vraiment une méthodologie spécifique, c’est vraiment une structure destinée à être adaptable à une large gamme de situations
Agile n’est pas vraiment l’équivalent de Scrum. Il y a d’autres méthodologies Agile comme Kanban
Il est assez facile de voir que le mot ‘Agile’ est aussi utilisé très largement pour qualifier une méthodologie spécifique et bien définie quand ce n’est pas le cas. Le dénominateur commun des méthodologies que les gens appellent ‘Agile’ consiste en ce qu’elles sont flexibles et adaptatives et soulignent la créativité et l’innovation dans un environnement incertain plutôt que la planification et le contrôle pour une prévisibilité avec des niveaux moindres de certitude. C’est pourquoi, je préfère utiliser le mot « adaptatif » au lieu du mot ‘Agile’ lors de la comparaison avec ‘en cascade’ (dirigé par un plan).
Pourquoi comparer « Dirigé par un plan » et « Adaptatif » est-il plus précis et objectif ?
Voici pourquoi je préfère utiliser une comparaison entre « Adaptatif » et « Dirigé par un plan » plutôt que ‘Agile’ versus ‘en cascade’ :
C’est plus précis
« Dirigé par un plan » n’implique pas de méthodologie spécifique. C’est une caractéristique d’une large gamme de méthodologies ce qui je pense décrit plus exactement ce dont parlent les gens.
C’est plus objectif
Le mot ‘Waterfall’ associe des tas de connotations très négatives car il ramène au modèle original ‘Waterfall’ défini en 1970 et ce que les gens appellent ‘en cascade’ peut aujourd’hui avoir peu de ressemblance avec l’original de 1970. L’expression « Dirigé par un plan » ne traine aucun de ces bagages négatifs.
Quand les gens dans la communauté Agile comparent ‘Agile’ et ‘en cascade’, c’est d’habitude dans le contexte Agile est bon et ‘en cascade’ mauvais et ce n’est ni vraiment précis ni objectif. Dire « ‘Agile’ est meilleure que ‘en cascade’ » s’apparente à dire “une voiture est meilleure qu’un bateau”.
Les deux ont des avantages et des inconvénients selon l’environnement dans lequel vous évoluez:
Une approche ‘dirigée par un plan‘ donne à son meilleur dans les projets qui ont un faible niveau d’incertitude et exigent un fort niveau de prévisibilité
Une approche adaptative marche mieux dans les projets qui ont un niveau élevé d’incertitude et exigent un focus sur la créativité et l’innovation pour trouver une solution optimum plutôt qu’une orientation sur la planification et le contrôle pour atteindre la prévisibilité
En bref
livre sur Amazon
Je ne pense pas avoir la moindre chance de faire en sorte que les gens cessent d’utiliser la comparaison ‘Agile’ versus ‘en cascade’ qui est trop largement utilisée. Je l’utilise même moi-même parfois parce que c’est une façon commode et simple de décrire quelque chose qui est en réalité beaucoup plus complexe. J’espère juste que les gens comprennent combien c’est une simplification excessive et à quel point ce peut être imprécis et trompeur.
L’auteur de ce billet, Chuck Cobb est l’auteur du livre « The Project Manager’s Guide to Mastering Agile » et il a développé un cours appelé “Learn the Truth About Agile Versus Waterfall” qui fournit plus de détail pour aider les gens à voir ces approches depuis une nouvelle perspective comme complémentaires l’une à l’autre plutôt que en compétition : Free Agile versus Waterfall course
N’hésitez pas à poster vos commentaires sur ce livre, ce cours et/ou ce billet…
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
DantotsuPM.com 
