Certification PMP®: Quelle vraie valeur?

Est-ce que ces référentiels apportent une vraie valeur? Est-ce une vraie différentiation? Quel est réellement l’intérêt d’être certifié PMP®?

Autant de questions qu’on peut se poser sur PMP® comme sur la plupart des autres certifications du marché. Cependant, PMP® tient une place un peu à part.

Le métier de chef de projet est un métier qui demande de multiples compétences: des savoirs, des savoir-faire, et d’avantage encore de savoir-être. Les meilleurs chefs de projet ne sont pas que des techniciens du Gantt et de l’earn value management; ils ont du doigté, de la diplomatie et savent faire avancer les sujets malgré les difficultés. « Une main de fer dans un gant de velours »: voilà un adage qui leur correspondrait bien selon moi.

Bien sûr, tous les projets n’ont pas le même niveau de complexité ou les mêmes enjeux. Il est naturel de croire que les gros projets à forts enjeux doivent mobiliser plus de compétences que les plus petits. Néanmoins, les domaines de compétences sont communs et gagnent à être tous utilisés. Ce n’est pas parce qu’un projet est « petit » qu’il faut zapper la gestion des risques, l’implication des parties prenantes, la communication et la contractualisation par exemple. Ce sont des aspects importants de tous les projets.

Dans ce sens, PMP® est un vrai livre de chevet: En effet, il contient toutes les connaissances que devrait maîtriser un chef de projet worldclass. Bien sûr, PMP® n’est pas la bible; d’autres référentiels existent. Mais la classification des connaissances en domaines (« knowledge areas ») en donne une vision claire et en correpondance avec le cycle de vie du projet (Initiating, Planning, Executing, Monitoring & Controlling et Closing).

Les chefs de projet qui se plongent dans le référentiel trouvent tous que le contenu du PMBOK© Guide aurait pu leur servir dans de nombreux cas. Dans les situations difficiles, techniquement ou « politiquement », dans des contextes culturels forts, avec des parties prenantes aux enjeux divers souvent antagonistes. Le livre contient de nombreux outils, techniques et méthodes qui apportent immédiatement. Rien de révolutionnaire évidemment car le PMBOK© Guide recense les outils existants, mais les mets dans l’ordre et là où ils sont les plus efficaces.

Le processus de certification est lui aussi à forte valeur car il s’appuie sur 3 piliers:

  • Connaitre en détails le PMBOK© Guide,
  • Avoir une expérience opérationnelle reconnue: 3 ou 5 années en fonction de son niveau d’études
  • Réussir un examen exigeant de 200 questions, portant sur tout le référentiel, et extrêmement sécurisé

Un certifié PMP® ne l’est pas par hasard: réussir l’examen PMP® c’est l’aboutissement d’une vraie préparation et d’une compréhension profonde du référentiel. Impossible de se présenter à la certification parce qu’il y avait de la lumière: la personne mal préparée n’a quasiment aucune chance de la réussir.

C’est pour toutes ces raisons que la certification PMP® est parmi les plus reconnues et les plus recherchées sur le marché. Un certifié PMP®, c’est forcément un chef de projet expérimenté, qui connait bien les outils, méthodes et processus de gestion de projet, quelqu’un d’impliqué dans sa profession, et souhaitant évoluer. N’est-ce pas potentiellement une excellente recrue pour l’entreprise?

Vous vous souvenez des 4 principes agiles?

Même si on va prendre SCRUM en example, les autres méthodes agiles partagent les mêmes principes fondateurs. Ces principes changent les façons classiques de travailler et l’organisation de ce travail. Ils sont très forts si on cherche à les suivre, même s’ils peuvent paraitre triviaux. Passons-les en revue et identifions les impacts qu’ils génèrent.

Principe n°1: Individus et échanges plus que processus et outils

Avant d’entrer dans les détails, juste un retour sur les 3 rôles principaux formant la Scrum Team:

  • le Product Owner, responsable d’orienter le développement en fonction des besoins des utilisateurs ou clients
  • la Development Team, responsable de tout le cycle de production pour aboutir à un produit fonctionnel (livré par itérations) y compris l’architecture, les développeurs, les testeurs, etc
  • le Scrum Master, chargé de l’adoption de la méthodologie dans l’équipe et dans l’entreprise

Ce principe a de nombreuses conséquences. Tout le monde s’accorde à dire que les personnes travaillent mieux ensemble quand elles sont en immersion et en présence les unes avec autres. De fait, Agile déconseille le travail à distance et les équipes délocalisées. Bien sur, il y a la vraie vie; mais c’est une raison majeure de dysfonctionnement dans les équipes de développement.

Ceci amène à une structuration différente des équipes travaillant en agile: elles doivent travailler ensemble, physiquement, et pour obtenir le maximum d’efficience, elles doivent être autosuffisantes. On entend par là être en mesure :

  • de résoudre elle-même les problèmes liés au développement (techniques, architecturaux, de performance, etc)
  • de s’auto-organiser pour atteindre ses objectifs (en gérant elle-même sa composition et son planning par exemple)
  • de négocier les objectifs des Sprints avec le Product Owner
  • d’organiser ses Sprints de façon autonome
  • d’améliorer sans cesse ses compétences et sa performance

Autre conséquence liée à l’autonomie de la Development Team: elle n’a pas besoin de manager. C’est aussi pourquoi le Scrum Master n’est pas un manager mais un leader; SCRUM entends par là qu’il mène une mission d’accompagnement et de facilitation; pas hiérarchique.

Principe n°2: Produit fonctionnel plus que documentation pléthorique

Cela ne veut pas dire: pas de documentation bien entendu. Mais cette documentation se déplace et change de forme. Le code doit être auto-portant pour permettre aux équipes de développer efficacement et de partager son code en cas de turn over. Les modes opératoires se transforment en vidéos d’utilisation mettant en situation l’utilisateur du développement. Comme l’agilité repose sur l’implication des utilisateurs (dans le grooming ou progressive refinement et dans les Sprint Reviews), les utilisateurs voient avancer le développement et se l’approprient mieux.

L’idée de « produit fonctionnel » amène aussi la question de la qualité des développements. En effet, le produit livré, même itérativement à la fin de chaque Sprint, doit être terminé et utilisable. Ceci pose la question de ce qui est « terminé » (en production? Sans bugs? Avec un nombre de bugs acceptable? Après le support de formation?). Ceci amène aussi le besoin de livrer un produit de qualité: il n’y a pas pire qu’un produit buggué passé en homologation aux utilisateurs.

Principe n°3: Collaboration du client plus que négociation du contrat

Bien sûr c’est une des dimensions fortes des méthodes agiles: on cherche à éviter les effets tunnel. Tout le monde a vécu les problèmes d’interprétation de diverses équipes qui se transmettent des informations par documents interposés. Le meilleur moyen de se comprendre c’est de se parler, pas de s’écrire (cf la littérature pléthorique sur la communication verbale/non verbale/gestuelle etc).

Il est aussi très difficile de préciser le périmètre d’un développement applicatif ex nihilo: qui est capable de spécifier sur 100 pages les besoins détaillés en début de projet, alors que les idées ne sont pas toujours très claires au moment du lancement? Personne. Il est bien plus efficace de co-construire les livrables et de faire des boucles de rétro-action courtes. Seeul le client/utilisateur peut dire ce dont il a envie, et le lui montrer est le meilleur moyen de lui faire exprimer. Montrer souvent, c’est avoir des retours fréquents.

Ce point pose la question de la durée des Sprints: un mois tel que préconisé par SCRUM. C’est à régler selon les projets mais la durée des Sprints ne peut pas être modifiée (perte d’efficience et déstabilisation). La bonne durée est à fixer en fonction de la capacité à produire de la Development Team et de son besoin d’obtenir des retours.

Principe n°4: Réactivité au changement plus que suivi d’un plan

Enfin, un dernier principe très fort: droit à l’erreur, mais une erreur rapide. Fail but fail fast. Avec le développement classique le tunnel peut durer plusieurs mois; en agile c’est au maximum un Sprint. En agile, le changement c’est le moteur de la méthodologie; les Sprints sont des outils pour rebondir sur les changements.

Le fonctionnement par Sprint pose quand même la question de la planification car agile ne veut pas dire aucune planification. Deux aspects: en début de Sprint on a bien un évènement qui s’appelle « Sprint Planning », mais dont la portée n’excède pas le Sprint qui vient. La planification plus long terme s’articule autour de la gestion des releases mais elle ne répond pas au besoin de planification d’un projet de développement long. Vous trouverez dans un article précédent une discution sur la problématique de la planification et de la visibilité pour les instances dirigeantes d’un projet de développement agile.

Ces différents principes, si on cherche à les implanter effectivement, bouleversent les habitudes de pilotage classique des projets de développement: les respecter est important pour la réussite d’un projet de développement agile.

Et si le meilleur atout d’une méthode agile, c’était une méthode classique?

Avez-vous déjà essayé de vendre à un DAF un projet de développement dont on ne connait ni les contours, ni les coûts ni la date de fin?

Évidemment, présenté comme ça c’est un peu brutal. Mais qu’est-ce que voit un décideur d’un projet agile si ce n’est exactement ça? Et je ne parle pas des financiers, à qui la démarche est le plus souvent totalement étrangère.

Bien sûr ce n’est pas ce que dit SCRUM (80% des projets de développement agiles s’appuient sur SCRUM). Mais dans les faits, c’est pourtant bien ce qui se passe car les entreprises ne sont pas toutes en mode agile. Elles ont besoin de visibilité, les différents acteurs ont du mal « payer pour voir »: il faut convaincre et pour convaincre il faut montrer.

Deux cas assez fréquents où il faut donner de la visibilité: lorsque l’entreprise souhaite expérimenter/adopter une méthode agile, et lorsqu’on a vécu un échec après l’avoir expérimenté. Dans les deux cas il y a une attente forte de contrôle.

Il n’y a pas dans SCRUM d’étape sur le contrôle. Les Sprint Reviews et Sprint Rétrospectives sont bien des jalons où des feedbacks sont générés respectivement sur les fonctionnalités et sur la méthodologie. Mais c’est très insuffisant pour (re)donner confiance et avoir de vraies perspectives.

Ce contrôle est d’ailleurs utile aux équipes qui ont souvent, elles-aussi, besoin de se rassurer. Pensons par exemple au Product Owner, qui porte seul la responsabilité de l’atteinte des objectifs du développement agile: que peut-il faire pour garantir l’alignement du développement avec les objectifs de l’entreprise? Comme va-t-il chercher le financement? Comment fait-il la preuve que ces objectifs ont été atteints? Comment formule-t-il ces objectifs? Comment fait l’équipe de développement, qui doit embarquer assez souvent des évolutions extérieures au projet agile? Comment l’équipe gère-t-elle la non-disponibilité des parties prenantes et leur motivation (rappel: le Scrum Master n’est pas un manager et la Development Team est auto-suffisante)?

Dans la vraie vie, la Dévelopment Team n’est pas dédiée; elle ne dispose pas de toutes les ressources nécessaires: parce qu’elles n’ont pas besoin d’être présentes tout au long du développement et/ou parce que ces ressources sont toujours mutualisées avec d’autres projets.

Autant de questions fondamentales qui n’ont pas de réponse dans SCRUM. Autant de sources de dysfonctionnement et les équipes ne sont pas armées pour y faire face.

Finalement de quoi parle-t-on? On parle de recentrer les équipes agiles sur leur cœur de métier: le développement. Mais développer une application ce n’est pas seulement écrire du code. C’est aussi gérer des risques, respecter une feuille de route, rendre compte d’un budget. Bref, c’est gérer un projet.

N’en déplaise aux puristes, la meilleure façon de gérer un projet de développement agile, c’est de l’encadrer avec une gestion de projets classique.

Je sais ça fait tâche. Mais c’est du bon sens: A moins que l’entreprise ne choisisse de consommer un certain budget « pour voir » et que le périmètre du développement soit vraiment restreint, faire du pure agile est très risqué.

Comment faire?

Tout le monde a depuis longtemps fait la correspondance entre classique et agile via les Sprints: les Sprints sont en agile ce que les Séquences sont en classique (pour PRINCE2 par exemple). Et finalement, l’équipe spécialiste de PRINCE2 c’est la Development Team de SCRUM. Mais comment réconcilier la vue court-terme de SCRUM avec la vue long terme de PRINCE2?

En fait, il y a un point de contact naturel: le Sprint Goal. A chaque début d’itération (Sprint Planning), la Development Team définit les objectifs du Sprint à venir dans un Sprint Goal. Ce Sprint Goal permet à l’équipe de développement de « garder le cap », et ne pas oublier les objectifs du Sprint pendant son exécution.

Ce Sprint Goal est un excellent moyen de confronter le périmètre à réaliser dans le projet et le périmètre réalisé dans le Sprint. Visuellement, c’est lui qui fait le lien dans un Plan Projet classique avec les objectifs de la Development Team. On a ainsi tous les outils pour donner de la visibilité à l’entreprise, voire au sponsor du projet de développement (rôle décrit nulle part dans SCRUM bien évidemment).

Alors? Est-ce que le meilleur atout d’une méthode agile, ce n’est pas une méthode classique?

En savoir plus: Retrouvez la formation Skills4All de préparation à la certification SCRUM Master ici: https://www.skills4all.com/formation-certification/gestion-de-projet/23-SCRUM-methode-agile/certification-professional-scrum-master-PSM1/

ITIL© à la Direction Générale: une drôle d’idée? Pas si sûr…

Bien sûr ITIL© c’est IT Infrastructure Library. Mais prenons un peu de hauteur.

Le transporteur qui cherche à traiter les dysfonctionnements sur ses camions, et à en comprendre les causes pour les éradiquer, ne fait-il pas de la gestion des incidents et des problèmes à la ITIL©? Sa gestion de parc auto-mobile ne pourrait-elle pas s’appeler CMDB? Pour gérer la saisonalité de son business, ne devrait-il pas utiliser la gestion de la demande? Gérer les évènements sur sa flotte serait certainement la meilleure façon d’améliorer la disponibilité de ses camions et la durée de vie de ses équipements… Pour assurer la satisfaction de ses clients, il gagnera certainement à implanter un processus de relation business appuyé sur des contrats de services.

On vient de parler, peut-être sans s’en rendre compte, 9 des processus ITIL© les plus connus. A-t-on parlé de serveurs? D’ordinateurs? D’applications?

Non.

Les principes sous-tendus par ITIL© sont bien plus larges que le seul domaine IT. Ce sont des principes qui soutiennent toute activité basée sur une relation client-fournisseur.

Depuis la version 3 certains processus sont vraiment en prise avec la stratégie de l’entreprise. On peut parler de gestion financière, de Stratégie des Services qui s’apparente à du marketing, de gestion des relations business qui ressemble trait pour trait au commercial et au portefeuille de services.

La gestion de portefeuille de services d’ITIL© pourrait apporter une grande valeur pour toutes les entreprises, quelque soit leur taille. Dans ce processus, explicité en détails dans le livre « Stratégie des Services », on explique comment piloter les investissements informatiques de l’entreprise, choisir les bons projets, les prioriser, et équilibrer ces investissements en balançant le risque et le ROI. Supprimez le mot « informatique » dans la phrase précédente et vous avez une gestion des investissements d’une entreprise à la mode MoP© (Management of Portfolios) qui traite exactement ce sujet au niveau de plus élevé de l’entreprise.

Autre processus ITIL© qui gagnerait à être prolongé à son bon niveau: la gestion des changements. Beaucoup de DSI l’ont implanté pour tenter de maîtriser les changements dans le système d’information. Mes ces changements sont une conséquence de changements dans le métier ou les processus de l’entreprise. Le même processus pourrait donc embarquer les changements « métier », car ils nécessitent une évaluation d’impact au même titre que les changement IT. Beaucoup de changements IT (même si ITIL© ne les décrits pas spécifiquement) patissent d’une définition insuffismament claire ou d’une évaluation insuffisamment travaillée au niveau du métier, avant de se traduire en changement dans le SI. On n’adresse d’ailleurs pas tous les changements de la même façon, car certains sont opérationnels (risque faible ou maîtrisé), tactiques (modification d’un processus métier) ou stratégiques (changement de métier). Les efforts ne sont bien sûr pas comparables. ITIL© nous décrit comment gérer ces différents niveaux de changement.

Encore une fois, on rejoint le référentiel MoP© qui décrit l’articulation entre la transformation de l’entreprise (à l’aide de projets et programmes) et les opérations courantes, qui sont l’ADN de l’entreprise.

Alors? S’inspirer d’ITIL© dans une Direction Générale: une idée saugrenue?

En savoir plus: Formez-vous à ITIL Foundation pour le meilleur prix. Retrouvez l’offre Skills4All sélectionnée pour vous: https://www.skills4all.com/course/index.php?categoryid=9

S’il-vous-plait, réfléchissons avant d’agile!

« Soyons agiles », « entreprise agile », « budgets agiles », « équipes agiles »… Arrêtons!

Arrêtons de penser que l’agilité est la réponse à tous les problèmes, mêmes ceux qui ne sont pas identifiés…

Les méthodes agiles, ça ne fonctionne pas pour tout: en fait, ça ne fonctionne bien que dans quelques cas de figure précis:

  • on ne sait pas définir précisément le produit/service à réaliser
  • ET qu’il peut être construit itérativement
  • ET qu’on accepte de le sortir alors qu’il n’est pas fini

Explicitons un peu ces 3 éléments.

On ne sait pas définir précisément le produit/service à réaliser

Vous savez décrire précisément le périmètre? N’utilisez pas une méthode agile! Il y a tous les outils nécessaires dans les méthodes classiques pour adresser les risques et les changements. Il y a un effort à fournir dans l’expression du besoin, mais que de temps gagné par la suite… Mais attention, ne pas savoir(vouloir) décire précisément le périmètre n’est pas une « excuse » pour passer en mode agile: les itérations (sprints) sont des phénomènes vivants difficiles à maitriser. Paradoxalement, le Product Owner responsable d’orienter/traduire les besoins des utilisateurs et les représenter, doit avoir une très bonne maîtrise du produit/service à développer. Ce rôle est central dans les méthodes agiles et les volontaires sont difficiles à recruter…

il peut être construit itérativement

même si un des slogans de l’agile est « on peut se tromper, mais le plus vite possible », les allers/retours et changements de directions en cours de développement sont déstabilisants et il vaut mieux les éviter. Etre agile, ça ne veut pas dire s’agiter: un temps de réflexion est nécessaire avant de se lancer. Il faut également que le produit/service puisse être constitué de briques agrégées les unes aux autres, avec des bases solides posées dès le début.. Sinon, gare aux rétro-pédalages douloureux. Ce socle initial est une question difficile à organiser en mode agile, car il nécessite au contraire de bien comprendre le périmètre à livrer. D’où l’importance du Product Owner.

On accepte de sortir le produit/service alors qu’il n’est pas fini

En effet, une composant centrale des méthodes agiles, c’est l’interaction avec le client/utilisateur. Il faut lui montrer rapidement quelque chose sur lequel il puisse réagir, rebondir et qu’ils puissent s’approprier. C’est une contrainte forte qui amène son lot de déconvenues: de la frustrations lorsque les livraisons ne suivent pas ou la qualité n’est pas au rendez-vous; de la démotivation lorsque les fonctionnalités demandés ne sont pas priorisées comme le souhaitent les utilisateurs; du septiscisme lorsque l’ergonomie ou le visuel n’est pas soigné, voire l’impasse lorsque les évolutions techniques ou de plate-forme ne sont jamais priorisées par les utilisateurs. Ceci implique une équipe d’utilisateurs forte, impliquée et motivée à 100%, prête à s’investir sur la durée et ouverte au dialogue!

Dans tous les cas, l’agilité nécessite une formation préalable, car ces méthodes changent radicalement de l’approche classique. C’est un petit investissement qui vous rendra de grands services..

En bref, et à moins que vous cherchiez à développer 3 pages de code d’une application non stratégique, posez-vous la question plutôt en ces termes: suis-je sûr de ne pas pouvoir utiliser une méthode classique?!

Retrouvez la formation Skills4All de préparation à la certification SCRUM Master ici: https://www.skills4all.com/formation-certification/gestion-de-projet/23-SCRUM-methode-agile/certification-professional-scrum-master-PSM1/