Archive | outils et méthodes RSS feed for this section

Le Système d’information des Ressources Humaines ou SIRH, 50 nuances plus sombres…

5 Juil

Auteur : Yohann Romand, Consultant Senior Projets, Cabinet IQar, www.iqar-france.fr

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…).

money, money, money...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

3 pratiques Agiles faciles que votre équipe peut commencer dès aujourd’hui

29 Juin

3 Easy Agile Practices Your Team Can Start Today http://projectbliss.net/agile-practices/ par Leigh Espy

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.

Les 3 pratiques suggérées sont ici de bonnes démonstrations des valeurs Agiles que j’ai discutées dans A PM’s Guide to Agile Software Development

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 :
  1. Qu’avez-vous fait hier ?
  2. Sur quoi travaillez-vous aujourd’hui ?
  3. 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 :
  1. Qu’est-ce qui a fonctionné bien pour nous ?
  2. Qu’est-ce qui n’a pas bien marché ?
  3. 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.

démonstrationLes 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 !

Rencontres sur le management de projets – 9 au 15 Juillet

18 Juin

Quelles rencontres sur le management de projet puis-je vous recommander en ce mois de Juillet 2018 ?

Los Tres Amigos sur ScrumPulse, les premiers pas vers l’Agilité sur PMI, change management projects, sont les wébinaires que je retiens avant peut-être pour vous de bien terminer la seconde semaine de Juillet sur les plages anglaises pour Agile on the beach !

The 3 Amigos is an Agile technique to balance between no collaboration between people with different perspectives and involving an entire team in discussing all the details of every increment of work.

Lundi 9

When it comes to Backlog Refinement, phrases such as “split the user stories”, “use the three amigos”, and “refine when necessary” are often used to describe ways of doing so, but how can you be sure that you are refining in the most effective way?

Incorporating Agile Practices in a Waterfall Environment: There are several key Agile practices that waterfall teams can use to improve agility without going through the full Agile transformation and staying within the waterfall umbrella-or even adopting a hybrid Agile/Waterfall approach.

Mardi 10

L’idée du WAWLab est née de la rencontre de quatre passionnés, professionnels expérimentés et engagés dans leurs entreprises du territoire Paris-Saclay. Ils sont tous convaincus que le chemin du succès passera par le bien-être au travail de ses acteurs. Ayant chacun déjà exploré des démarches innovantes d’amélioration du bien-être personnel et collectif dans le monde du travail, ils ont choisi de mettre leurs talents, leur enthousiasme, leurs convictions, et leurs carnets d’adresse en commun, pour faire du territoire en devenir qu’est Paris-Saclay, un champ d’expérimentation. Venez découvrir le laboratoire du bien-être au travail !

Mercredi 11

Most of PMI PMBOK is dedicated to planning processes, the project management process has only one step dedicated to execution and all the rest are planning steps. As a result, it may be perceived that the key for project success is planning and that the most important skills for a project manager are planning skills. Is this really the case?

Jeudi 12 & Vendredi 13

This year is set to be another amazing year on the beach. Opening Agile on the Beach 2018, we welcome Gert Gigerenzer from Berlin, Germany as our first keynote speaker. Internationally known for his award-winning popular books, Calculated Risks, Gut Feelings: The Intelligence of the Unconscious, and Risk Savvy: How to make good decisions.

CertYou est partenaire de DantotsuPM

PMI is a registered mark of Project Management Institute, Inc.

Microsoft Planner ou Microsoft Project: Lequel utiliser pour manager vos projets ?

30 Mai

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 !

Microsoft Planner vs Microsoft Project: Everything You Need to Know https://www.sherweb.com/blog/o365-microsoft-planner-vs-microsoft-project/

À 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.

Que signifie vraiment ‘en cascade’ (Waterfall) dans le management de projet ? Comment les gens utilisent-ils cette expression ?

28 Mai

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?

http://managedagile.com/waterfall-really-mean/ by Chuck Cobb

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 :

Dr. Winston Royce’s 1970 Waterfall Paper

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…

Image

le combiné « Guide PMBOK® + Guide pratique des méthodes Agiles » du Project Management Institute est disponible en français

19 Mai

Livres sur Amazon

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.

Le PMBOK® guide – Sixième édition contient maintenant des informations détaillées sur Agile; tandis que le Guide de Pratique Agile, créé en partenariat avec Agile Alliance®, sert de passerelle pour connecter méthodes prédictives et agilité. Ensemble, ils constituent un outil puissant pour les managers de projets.

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

Gestion de Programme : Comparatif MSP® (AXELOS) et PgMP® (PMI®) par Marc Burlereaux !

14 Mai

Commençons par un petit rappel des caractéristiques du Responsable de Programme versus Chef de Projet

 Le Chef de Projet, certifié PMP®, PRINCE2® ou autres ou pas

  • Est responsable de diriger les tâches d’un projet
  • Est responsable du succès d’un projet
  • Gère le projet en respectant la triple contrainte : objectifs, coûts et délais
  • Est responsable de projets individuels

Le Responsable de Programme, certifié PgMP®, MSP® ou autres ou pas

  • Projet ou Programme ?

    Gère un groupe de projets qui partagent un objectif stratégique commun

  • Travaille pour assurer la réussite ultime du programme
  • Démontre suffisamment d’expertise et de connaissances pour prendre des décisions qui vont dans le sens des objectifs stratégiques
  • Définit et initialise les projets en assignant les chefs de projets qui vont les gérer

Mon parcours

Dans le monde de la transformation bancaire

Évoluant dans le monde du changement depuis la fin des années 1980, au début à Paris au Crédit Lyonnais à La Défense et en Suisse depuis 1987, je suis resté focalisé dans le monde bancaire et particulièrement celui de la Banque Privée. Après quelques années en tant qu’Analyste Métier, je me suis tourné vers des tâches de coordination que ce soit d’équipes, de projets et enfin de programmes. En plus de cette double compétence bancaire et coordination, je me suis frotté à la mise en place de plateformes bancaires, programmes de transformation souvent trop ambitieux et donc risqués. J’ai connu des échecs, j’ai beaucoup appris humainement et professionnellement, et j’ai aussi contribué à motiver les équipes à délivrer afin de répondre aux objectifs stratégiques.

Dans le monde des certifications PMI (américain)

Très vite, il m’est apparu vital d’assurer ma formation de manière permanente pour une amélioration continue de mes performances, pour m’enrichir de la confrontation avec d’autres personnes venant d’environnements différents, que ce soit culturellement ou professionnellement. Et aussi, et ce n’est pas le moindre avantage, pour m’enrichir en anglais.

Je suis une personne de réseau, donc tout mes rencontres ont naturellement tracé ma voie. Luigi Ribon et Alexandre Matthey m’ont mis le pied à l’étrier du PMI en 2000 et je ne peux que les en remercier. Ce voyage m’a d’abord conduit à une certification PMP®, obtenue laborieusement en 2005. Elle est venue sanctionner 20 ans d’expérience projets et j’ai appris énormément : j’ai regretté de ne pas l’avoir obtenue plutôt. Ensuite, en 2008, j’ai commencé ma formation pour obtenir le PgMP® (gestion de programme) en ayant participé à deux programmes majeurs de transformation métier en 2000 et 2005. Je remercie encore mon chef de l’époque Sébastien Bouchet d’avoir cautionné cette formation. Le parcours fut long, douloureux mais enrichissant : Ardi Gorashy et Ginger Levin furent mes deux coach, tout deux des membres renommés de PMI. Vous pouvez trouver un retour d’expérience détaillé ici.

Cela m’a permis de passer la vitesse supérieure et de mieux comprendre que la gestion de programme permet notamment un meilleur accompagnement de la transformation métier.

Ensuite j’ai complété ces certifications par d’autres dans les domaines de l’analyse métier, de l’agilité, de la gestion des risques … ce qui conduit certains amis facétieux à me coller le titre de Général Russe du PMI, avec mes décorations… Mais il y a pire, n’est-ce pas Olivier Lazar ? 😊

Dans le monde des certifications AXELOS (anglo-saxon)

Et puis soudainement, je me suis retrouvé à collaborer au sein du cabinet Daylight à Paris, où travaille un ami d’enfance, François Delignette, que j’ai retrouvé au sein de l’association PMI. Je sortais d’une grande banque anglaise, organisation très mature en terme de méthodologie et qui utilisait une méthode de transformation maison à la fois inspirée des standards PMI et AXELOS. Le patron de Daylight, Fadi El Gemayel, m’a alors convaincu de passer la certification MSP® que je n’avais pas encore, car c’était requis pour assurer des mandats de conseil client. D’abord réticent et un peu agacé de devoir encore me coltiner une certification alors que le sésame PgMP® devait assurer de mes compétences : Je ne peux que m’en féliciter. J’ai tellement apprécié l’approche que j’ai très rapidement passé la certification PRINCE2® pour la gestion des projets, basée également sur la notion de cas d’affaire.

QRP International est Partenaire de DantotsuPM

Que m’a apporté MSP® (Managing Sucessful Programmes)

Une méthode simple et structurée à la fois, excellent guide pour la mise en place et l’exécution de programme. Tout est basé sur le cas d’affaire et les bénéfices attendus pour répondre à la stratégie.

team work / complémentaritéUne sorte de canevas à adapter à la taille et à la complexité de l’organisation et du programme.

Une définition claire de rôles essentiels comme le Sponsor et le Responsable de la Gestion du Changement.

La nécessité de définir le Modèle Opérationnel Cible pour donner une direction claire et mieux structurer la livraison des bénéfices attendus par le programme.

Des conseils pragmatiques pour assurer la création d’un PMO (Program Management Office) efficace.

Cela représente un cadre efficace dans lequel peuvent s’insérer des artefacts de la méthode PMI, par des exemples de documents ou de modèles complétant le tout.

Quelle est la plus-value de MSP® dans l’accompagnement de la transformation métier ?

MSP® & la gestion de programme MSP® (Managing Successful Programmes) définit le management de programme comme « l’action d’organiser, diriger et déployer de manière coordonnée un dossier ou un projet et des activités de transformation (le programme), pour atteindre des résultats et des profits d’importance stratégique pour l’entreprise ».

Cette vision Programme permet :

  • D’aligner les livrables avec la stratégie de l’organisation,
  • De bien préparer l’organisation à la mise en œuvre des bénéfices,
  • De gérer tous les aspects de la transformation sans perturber les activités courantes.
 Le Modèle Opérationnel Cible !

Le Modèle Opérationnel Cible (ou Blueprint ou Target Operating Model) décrit les informations clés requises pour établir le design et les livrables qui vont constituer le système cible :

  • L’état actuel : comment l’organisation travaille actuellement
  • L’état futur : comment l’organisation travaillera quand le programme sera terminé.

Le Modèle Opérationnel Cible est composé de quatre éléments d’information selon le modèle POTI :

  1. Process – Comment l’organisation fournit les produits et services
  2. Organisation – Les personnes, la structure, les capacités utilisées pour délivrer les produits et services
  3. Technologie – La technologie, les outils, les immeubles qui supportent les opérations
  4. Information – la connaissance, les informations utilisées au jour le jour pour exécuter les opérations

La clarté de ma cible permet de structurer au mieux le programme afin de délivrer les bénéfices qui supporteront la stratégie de l’entreprise.

Comparatif rapide et personnel des deux certifications (MSP® d’AXELOS et PgMP® de PMI)

MSP®

  • Livre sur Amazon

    Cours d’une semaine pour préparer « Foundation » et « Professional »,

  • Relativement aisé à obtenir si on a bien lu le guide et si on de l’expérience dans la gestion de programme,
  • Investissement modéré (coût et temps),
  • Examen à livre ouvert s’appuyant sur des cas d’affaire,
  • Ne garantit pas l’employeur de recruter un expert de la gestion de programme,
  • Fournit au certifié un canevas pragmatique aisé à mettre en place dans une organisation,
  • Pas de développement du réseau professionnel, si ce n’est la rencontre des personnes assistant au cours présentiel.

PgMP®

  • Livre de préparation sur Amazon

    Cours d’une semaine pour préparer la certification. C’est juste un pré-requis qu’il faudra compléter par un investissement personnel considérable,

  • Il faut justifier d’une expérience de la gestion de programme en documentant des cas concrets qui seront revus et parfois audités : les personnes indiquées comme pouvant attester de la véracité des faits seront alors contactées,
  • Investissement important (coût et temps),
  • Examen de 4h00 sans consultation possible du support de cours,
  • Garantit à l’employeur de recruter un expert de la gestion de programme (de nombreuses candidatures, voire toutes, sont auditées et les références données doivent attester sur l’honneur de la véracité des expériences citées),
  • Fournit au certifié des modèles et une bonne compréhension des avantages de la gestion de programme,
  • Ouverture au réseau PMO qui favorise la mise en relation des professionnels de la gestion de projets et programmes, avec des événements organisés localement et le partage de ressources en ligne.

Conclusion : Je conseille de préparer les deux certifications, car elles sont très complémentaires l’une de l’autre.

Si vous êtes pressés et que vous souhaitez optimiser votre investissement, je conseille alors de commencer par MSP car une préparation rapide vous permet d’obtenir les éléments pragmatiques et concrets pour la mise en place des concepts de la gestion de programme.

“PMI,” “PMP,” “PgMP,” and “Project Management Institute” are registered marks of Project Management Institute, Inc.

Partenaire de DantotsuPM

PM4SD – les projets dans le tourisme conçus avec le développement durable à l’esprit ont un impact positif dans le long terme sur les destinations et les communautés

11 Mai

PM4SD Helping You to Go the Distance with Your Tourism Projects

Les projets touristiques peuvent être divers et varier en termes de durée, budget, secteur et de la variété de parties prenantes visées. Ces projets influencent souvent un large éventail d’activités économiques et sociales. En conséquence, ils ont un impact considérable sur le développement durable à un niveau local et aussi global.

Si un projet touristique est conçu en tenant compte de la durabilité, il peut avoir des effets de longue durée sur les bénéfices dans le temps pour les destinations et communautés, garantissant en outre qu’elles reçoivent le financement et les ressources nécessaires à la bonne exécution du projet.

Alors, qu’est-ce qui a un impact sur la nécessité de créer et de mener à bien des projets durables?

L’un des facteurs clés pour tout projet est les personnes impliquées dans ce projet. Le plus souvent, il s’agit de leadership et gouvernance efficaces; ceux qui dirigent le projet doivent être convaincus du bien fondé d’adopter une approche durable, et le projet doit avoir une approche pratique et structurée avec une compréhension claire de ce que le projet devrait produire en conséquence.

details online

Pour aider à comprendre les différents aspects de la gestion et de la réussite d’un projet de tourisme durable, PM4SD – Gestion de projet en développement durable est une méthodologie ciblée pour les gestionnaires de projets et les acteurs du tourisme.

APMG est partenaire de DantotsuPM

Quelles sont généralement les phases logiques dans les projets suivant une approche « Waterfall » (en cascade) ?

4 Mai

Si cette question vous est posée lors d’un entretien d’embauche, voici que répondre…

Quelle que soit la méthodologie de projet spécifique mise en œuvre dans une entreprise ou organisation, les projets qui adoptent une approche prédictive aussi nommée « en cascade » ou parfois « cycle en V »  suivent généralement les 5 phases suivantes:

  1. Initiation : Démarrage
  2. Préparation : Planification – Organisation
  3. Exécution : Réalisation du travail pour produire le ou les livrables
  4. Contrôle de la bonne exécution et de la progression dans l’exécution des tâches du projet
  5. Clôture et Acceptation des livrables

Pour aller un peu plus loin, vous pouvez en mentionner une trop souvent omise: 6. Réalisation des bénéfices.

Il s’agit lors de cette phase (qui se poursuit quand les produits et livrables du projet sont entrés en phase opérationnelle ou de production) de bien vérifier que les bénéfices escomptés au lancement du projet et identifiés dans le cas d’affaire sont atteints ou même dépassés.

Enfin, il peut être intéressant de mentionner que votre maitrise de ce type d’approche prédictive ne vous empêche en rien d’en connaitre d’autres plus adaptatives comme Scrum côté Agile voire que vous êtes capable de les combiner pour en tirer le meilleur.


DantotsuPM, le blog du management de projets, peut vous aider dans votre projet d’évolution de carrière dans le management de projets et de  changement de poste car j’ai sélectionné un réseau de recrutement à taille humaine et tout aussi profondément humain qui me fournit fréquemment des offres dans le domaine du management de projet, programme et PMO !

avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets

 

Les nouvelles de Microsoft dans le domaine du management de projets – Avril 2018: Découvrons le Planificateur Microsoft pour organiser le travail d’équipe !

30 Avr

Bonjour, comme chaque mois, je vous propose de découvrir une facette des offres et nouvelles de notre sponsor Microsoft.

En cette fin Avril, ce sera le Planificateur: Planner.

Page dédiée sur le site Microsoft France

Organiser et partager en toute simplicité

Planner permet à l’équipe de créer aisément des plans, d’organiser et d’attribuer des tâches, de partager des fichiers, d’échanger sur le travail en cours et de mettre à jour l’avancement du projet.

Ce qui frappe en premier lieu est la simplicité d’organisation et en conséquence d’utilisation de cet outil.

Il est en effet rapide avec Planner de créer un plan, constituer une équipe, attribuer des tâches et mettre à jour l’état d’avancement en quelques étapes simples.

Le travail est organisé très visuellement avec un tableau dédié par plan dans lequel les tâches peuvent être organisés en blocs ou compartiments. Elles peuvent être classées en fonction de qui les exécute, de leur état d’avancement…

Faciliter la collaboration dans l’équipe

La collaboration est grandement facilitée par cette visibilité de qui fait quoi et transparence sur la progression dans la réalisation des tâches. Bien sûr, il est possible d’attacher des pièces jointes aux tâches, de collaborer sur ces fichiers partagés et d’échanger, d’avoir des conversations, sur ces tâches. Tous ces éléments sont intégrés dans le plan pour un accès centralisé et simplifié.

Planner fonctionne sur tous les appareils, PC, tablettes et téléphones mobiles pour que tous les membres de l’équipe aient accès aux mêmes informations. Des notifications en mode « push » sont également possibles.

Pour le chef de projet, Planner permet de :

  • Stocker des fichiers dans la bibliothèque de documents associée à votre plan et collaborer sur ceux-ci.
  • Planifier des rencontres dans les agendas des membres de l’équipe et capturer et organiser les notes de ces réunions.
  • Définir et associer des check-lists aux tâches et leur associer des étiquettes visuelles (Urgent, UI/UX, Important…).
  • Joindre des fichiers, photos ou des liens directement sur une tâche.
  • Marquer ce qui est fait (non commencé, en cours, terminé/done, approuvé…) et ajouter des commentaires et dialogues entre membres de l’équipe, vous compris.

Bref, un très bel outil abordable et facile à prendre en main pour des équipes de taille moyenne sans la complexité ni la lourdeur d’outils plus complexes qui deviennent néanmoins nécessaires et bénéfiques sur de plus gros projets.

%d blogueurs aiment cette page :