Warning: Undefined array key "HTTP_ACCEPT_LANGUAGE" in /home/vaesoli/snippet-center/trql.website.class.php on line 511

Warning: Undefined array key "HTTP_ACCEPT_LANGUAGE" in /home/vaesoli/snippet-center/trql.website.class.php on line 389

ICI, LE TITRE

23-01-2024 18:05:28

PMO

Le prisme de l'Agilité, le prisme des méthodes traditionnelles : utile ou pas utile ?

Les tenants des méthodes agiles vous diront (très souvent) qu'un PMO est inutile et contre-productif, que c'est une construction qui émane d'une structure de type Command and Control.

Les tenants des méthodes traditionnelles, plus linéaires et sérielles, vous diront qu'ils ont besoin d'un PMO pour contrôler que les activités de projets sont réalisées comme la gouvernance et les processus le requièrent.

Ceci est l'expression d'une zone conflictuelle potentielle où les deux parties s'affrontent sans possibilité d'en sortir.

Dans une Transformation Digitale qui requiert le plus souvent la mise en place d'un PMO, il est nécessaire de commercer avec les uns et les autres, ceux d'en haut et ceux d'en bas.

Je défends l'idée d'un PMO qui agit comme un adaptateur / transformateur entre ces deux groupes pour que leurs objectifs propres puissent être réalisés avec le moins d'interférences négatives possible, une sorte d'interface bidirectionnelle qui génère une authentique valeur pour les uns et pour les autres.

Une perception difficile

Je longe une pente que mon contact avec des PMOs (Program Management Office ou Project Management Office), tout au long de ma carrière, a dessinée particulièrement abrupte et difficile. En 37 ans j'ai pu me frotter à plusieurs genres de PMO que j'ai fini par cataloguer en Directive et Supportive.

Je n'ai connu qu'un et un seul PMO Supportive; les autres, une bonne quinzaine, je les ai trouvés ― comment dire ? ― insupportables.

J'ai assisté à la naissance d'un, logé au creux d'une Transformation Digitale qui n'a jamais véritablement démarré. Il en a subi le sort, à savoir une forme d'avortement douloureux avant de repointer le bout de son nez sous d'autres auspices, finalement tout aussi pénibles.

J'ai eu aussi l'occasion ― et la chance ― d'en mettre un en place; je l'ai voulu comme le seul qui m'ait jamais été utile, secourable et obligeant. Je l'ai voulu Supportive. Ce fut une (très) belle réusssite et après 6 mois d'activité, le Management a estimé disposer des informations dont il avait besoin pour prendre des décisions éclairées ET les Chefs de projet, pour frileux qu'ils étaient au départ, étaient devenus enthousiastes. La Direction, pour nous remercier d'avoir fait un si bon boulot, a d'ailleurs organisé un Celebrate avec remise de petis cadeaux, une initiative suffisamment rare pour être notée. Je les remercie encore maintenant. Il faut dire que de dernier élève de la classe, nous nous étions hissés à la première place, donné en exemple pour d'autres départements.

Sur base de cette belle expérience, imposante en quelque sorte puisque chapeautant 25 chefs de projets en moyenne et entre 70 et 80 projets simultanés, on m'a donné la mission d'en mettre un en place dans une entreprise de Télécommunications / TV. Je l'ai voulu Supportive également mais sa transparence, valeur néanmoins suprême, a finalement gêné la Direction qui n'a pas souhaité se saisir des difficultés pointées.

Ces épreuves ont mené à des observations cathartiques dont il m'apparaît qu'elles pourraient être libératrices pour d'autres d'autant que le démarrage d'une Transformation Digitale s'accompagne souvent de la mise en place d'un puissant PMO. Les observations ont elles-mêmes entraîné par leur propre gravité des actions concrètes à leur suite. C'est ainsi que j'ai entrepris de démarrer un outil online, ouvert et gratuit, openPMO [1] , auquel le présent site est d'ailleurs relié.

Objectifs d'un PMO

L'objectif du PMO est de créer de la valeur pour le Management ET les équipes

L'objectif du PMO est de créer de la valeur pour le Management ET les équipes. En l'occurrence, le PMO ne travaille pas pour lui-même : il est au service de l'organisation, de toute l'oragnisation ou simplement de la chaîne de valeur où il opère.

Cette valeur est tout d'abord créée par l'utilisation de chiffres (orientée faits; importance de l'utilisation éclairée de métriques) qui permettent de décider ou d'orienter des actions concrètes tournées vers l'optimisation des ressources (toutes les ressources) d'une chaîne de valeur (Value Stream). C'est la valeur créée pour le Management.

Ensuite, il s'agit de créer de la valeur pour les équipes en leur fournissant guidance et assistance. Par guidance il faut entendre aide de terrain concrète, ancrée dans le réel et non dans le théorique et par assistance il faut entendre aide à faire et à ne pas faire. L'assistance qui se concrétise dans la mise en évidence de ce qui n'est pas à faire est absolument cruciale : aider les équipes à faire le tri entre ce qui est utile et ce qui ne l'est pas est une façon de répondre au principe de simplicité des méthodes agiles (the art of maximizing the things not done). Ce qui est vrai pour les équipes est vrai pour le PMO lui-même : faire le tri entre ce qui est précieux et ce qui est dérisoire. Cette assistance se manifeste également par le degré d'automatisation que permettent les outils choisis. Nous sommes là en plein dans l'Agilité et nous nageons dans les concepts de Lean.

Si perçu comme étant administratif alors le PMO est à la faute.

De fait, il existe quelques axes de création de valeur particulièrement intéressants communs; et il se pourrait très bien qu'au sein de votre propre organisation, d'autres axes se révèlent.

Les axes de création de valeur d'un PMO

La sélection des projets

Pour apporter de la valeur, un PMO doit résoudre des problèmes. L'un des problèmes les plus incontestablement épineux concerne l'encombrement de la ligne de construction, de la ligne d'assemblage : trop de travail à réaliser, dans des délais qui semblent impossibles et avec trop peu de ressources. Je crois bien avoir entendu ces raisons des milliers de fois être invoquées dans des conversations privées ou en meeting. L'encombrement de la ligne d'assemblage est lié à la sélection a priori des projets sur lesquels travailler. La résolution de lencombrement de la ligne d'assemblage et la sélection des projets sur base de données factuelles et chiffrées est une valeur essentielle à offrir au Management.

La nature EXACTE de ce problème tient à la manière qu'ont les organisations de démarrer de nouvelles initiatives qui n'ont pas … d'enveloppe physique. Cette absence de présence physique empêche de VISUALISER l'encombrement de la ligne d'assemblage, là où les équipes s'échinent à produire/construire ce qui leur est demandé. On ne voit pas la charge de travail, on ne la sent pas, on ne la comprend pas, et on l'oublie lorsque de nouvelles demandes se bousculent au portillon. Tout est dans la tête sans que les images mentales se forment. C'est un problème.

La tâche du PMO est alors de trouver le moyen de visualiser, et partant de faire comprendre, le problème auquel l'organisation est confrontée : le problème d'encombrement [2] ! Après la visualisation du problème, il faudra encore proposer des solutions !

Kanban

La seule façon de gérer un portfolio — je dis bien la seule — est de lui appliquer le traitement Kanban. Je n'entrerai pas ici dans l'ensemble de la théorie de la méthode. Qu'il me soit simplement permis de renvoyer le lecteur à David J. Anderson, Kanban: Successful Evolutionary Change for your Technology Business, 2010, un livre phare qui éclairera utilement sur la manière de gérer le travail à réaliser avec une approche pull plutôt qu'une approche push, un livre phare qui éclairera utilement sur la manière de gérer le travail à réaliser avec une approche pull plutôt qu'une approche push, un livre qui au détour de ses pages aidera également à prendre conscience qu'existent d'autres façons de gérer les budgets et les estimations de travail, bien que là n'est pas son propos central.

Donc, j'indique que la seule manière de traiter l'ensemble d'un portfolio est de lui appliquer la méthode Kanban qui commence, selon moi, à VISUALISER les projets selon 3 compartiments : les projets à démarrer, les projets démarrés, les projets terminés. J'ajoute à ces 3 compartiments un quatrième compartiment qui précède les 3 autres, le compartiment des idées, des nouvelles initiatives, des nouvelles ambitions, des espoirs, un compartiment que j'appelle Bubble. Les 4 compartiments s'enchaînent donc comme suit : Bubble, To Start, Started, Closed.

Les 4 colonnes d'un Portfolio : les 'projets' bougent de gauche à droite lorsque des conditions précises sont rencontrées

À ce stade 2 choses ! La VISUALISATION doit être TOTALE (visible de tous, transparence pour l'ensemble de l'organisation) et la dynamique du mouvements entre les compartiments doit être comprise (les projets migrent de gauche à droite).

La visualisation est capitale et remplace utilement des centaines voire des milliers de pages de rapports, tous très vite dépassés. En un clin d'œil, vous savez ce qui est en cours et ce qui reste à faire. La visualisation peut cependant induire en erreur car dans un tableau kanban habituel, chaque projet semble egal en importance à tout autre projet (une carte sur le mur vaut une autre carte sur le mur). C'est un biais cognitif qu'il est important de gommer mais c'est une autre histoire.

Une fois la prise de conscience établie, il est possible d'établir des pistes de solution ce que nous verrons plus loin mais qui passent immanquablement vers une priorisation efficace et vers un grooming [3] qui ne l'est pas moins.

En résumé, nous venons de voir que le portfolio devait être géré en mode kanban, que les projets [4] bougent de gauche à droite et qu'il est important de ne pas encombrer la ligne d'assemblage (colonne Started et son WIP ― Work In Progress) sous peine d'embouteillage Si chacun sait qu'en cas de trafic dense sur la route, on arrive plus tard à destination, il est curieux de voir qu'on ne se rende pas compte qu'en matière de gestion de projets le même principe s'applique : chacun devrait savoir que si le trafic est dense, la progression est lente !

Embouteillage Pékin (Creative Commons: photo par Axel Drainville) : plus le trafic est dense plus la progression est lente

Support à la vision / mission

Lorsque l'ensemble du portfolio devient ainsi visible il est possible d'anticiper les fonctionnalités qui contribuent à la vision / mission du portfolio, lui-même étant une partie cellulaire de la vision / mission de l'organisation. Ces deux notions ― priorisation - vision ― sont intimement liées; leur consanguinité est importante. Au fond, il s'agit de pouvoir établir les grands chantiers qui permettront de transformer la vision en roadmap et de populer lesdits chantiers avec des initiatives qui font sens.

La vue du portfolio présentée plus haut se traduit par une roadmap, une roadmap que vous ne pourrez établir QU'APRÈS avoir priorisé correctement les projets, (1) ceux qui sont en cours dans votre chaîne d'assemblage et (2) ceux que vous avez décidé de démarrer mais pour lesquels il n'y a pour l'instant pas de place.

La roadmap n'est rien d'autre qu'une vue du Portfolio articulée sur une ligne de temps. À la notion d'encours (WIP) on ajoute la notion de cône d'incertitude dont l'horizon est indépassable.

La réduction des gâchis

Le PMO doit être créateur de valeur pour les Executives (les gens d'en haut) et pour les équipes (les gens de la chaîne d'assemblage). Négliger une de ces deux parties revient à ne pas aider … l'organisation.

Pour simplifier, l'entreprise est divisée en deux grandes strates. D'un côté, vous avez les Executives et de l'autre le côté Usine qui s'occupe de la construction.

Les deux strates communiquent. Le PMO a pour objectif de satisfaire ces deux parties en permettant à l'ensemble de l'organisation de remplir sa mission / vision

Conformément au titre ci-dessus ― la réduction des gâchis ― il est important de réduire les frictions entre ces deux parties. Tout ce qui ne contribue pas immédiatement à de la création de valeur doit être éliminé. Cette volonté de réduire les frictions est clairement établie comme une contrainte forte de l'ensemble de Transformations Digitales que j'ai pu approcher. Je reprends d'ailleurs cette approche dans le diagramme ci-dessous qui schématise/généralise toutes les Transformations Digitales :

Deux cercles concentriques expriment des contraintes fortes qui s'imposent aux Transformations Digitales : la simplification (élimination des frictions) et la pression du AAA (Anything, Anywhere, Anytime)

Puisqu'il s'agit d'éliminer les frictions, puisqu'il s'agit d'éliminer les gâchis, alors pourquoi ne pas s'aider de l'élimination des 8 types standards de wastes de Lean, ce pour quoi j'utilise un truc mnémotechnique, DOMINO-TW. ?

8 types systématiques de gâchis : Defects, Over-Production, Movements, Inventory, Nion-Utilized Talents, Over-Processing, Transportation, Waiting

Je vais vous donner deux exemples très parlants. Tous deux ont eu pour décor une grande banque de la place, lors de deux missions totalement différentes, l'une étant de superviser la mise à niveau de tous les canaux de paiement pour SEPA et l'autre étant la mise en place d'un PMO pour le portefeuille de projets Infrastructure, soit un portfolio d'environ 75 projets avec 25 chefs de projet.

Case #1

Dans le premier cas j'étais chef de projet SEPA, année 2007. J'avais travaillé d'arrache-pied sur mon Project Initiation Document (PID) que j'étais très fier de pouvoir présenter après une semaine de travail intense.

Ce PID doit passer en comité pour y être présenté, examiné et approuvé. Pour ce faire, il me faut faire entrer mon document dans un flux automatisé à l'intention dudit comité (processus Sharepoint). Par contre, un bug m'empêche d'entrer le document pour le jour et heure limite. Le temps que le problème soit résolu, j'en suis remis à ne pouvoir présenter mon document que lors de la prochaine réunion du comité, soit 15 jours plus tard, or, 15 jours plus tard, le membre décideur principal du comité est malade : au final la présentation de mon document est postposée non pas de 15 jours mais d'un mois entier. Résultat : 5 jours de travail et … 20 jours d'attente, 20 jours de Waiting Time au sens de Lean. Si on s'octroie le droit de faire un petit calcul, on a 20% du temps de travail et 80% d'attente. Bilan très médiocre. En tant que PMO, qu'aurait-on pu faire pour éliminer la friction ?

Case #2

Cette fois, un Chef de projet, un Italien charmant avec l'accent qui met des fleurs partout, me demande mon aide. Je la lui offre bien volontier en tant que Delivery Manager aka PMO / Portfolio Manager. Lui aussi doit présenter un projet pour approbation par le même comité. Tous ses documents sont fin prêts et tous ont été soumis de manière automatique dans les temps. On va pouvoir passer son projet et démarrer tout de suite !

Mais patratra, non ! Ça ne passe pas et il reçoit un mail du secrétaire du comité, le matin même du jour où le comité se réunit, qui lui signale que le document XYZ n'a pas été joint à l'ensemble des pièces qu'il aurait fallu rentrer. Mon Italien ne comprend rien à cette affaire. Il essaye de me joindre pour guidance immédiate mais moi, je suis embrigadé dans un autre comité : impossible de répondre tout de suite. Dès ma réunion terminée on se rencontre très vite et on constate que le document qui manque est un document inutile pour son projet, un document où il n'y a rien à dire ("Je n'avais rien à vous dire mais je tenais à vous le signaler !"). Au final, nous avons passé 3 instances de réunion du comité et après moult palabres et frustrations, il nous a quand même fallu joindre le document en question … mais vide ! 3 jours de travail pour mon ami Italien, et 30 jours d'attente ! Un rapport 1 à 10. Belle performance ! J'étais le PMO; je n'ai rien pu faire pour lui. J'ai néanmoins réussi à faire en sorte que le document en question devienne un document optionnel dans l'application future du processus. J'espère que d'autres chefs de projet ont pu bénéficier de l'adaptation du processus, adaptation qui a été longue et fastidieuse.

Réduire le gâchis ce n'est augmenter le nombre de processus, ou augmenter le nombre de templates ou obliger les chefs de projets à rentrer des documents vides, faire hoqueter une ligne de production au rythme des meetings.

Au final, au travers de ces exemples, on voit bien en quoi on peut éviter des frictions, et donc éliminer des gâchis. Réduire le gâchis ce n'est pas augmenter le nombre de processus, ou augmenter le nombre de templates ou obliger les chefs de projets à rentrer des documents vides, faire hoqueter une ligne de production au rythme des meetings. Il ne s'agit pas de penser au tooling, ou même à la méthodologie, ou aux rapports à écrire sous des formes différentes, non ! Il s'agit de rationaliser, de simplifier, de se poser la question de l'utilité des choses ! De toute chose ! En la matière il est utile de se rappeler ce qu'Antoine de Saint-Exupéry disait : «La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.» Cette citation doit vous accompagner à tout moment pour simplifier et rationaliser les processus en place. L'idée est de voir (1) ce qu'on fait et qu'on doit continuer à faire, (2) ce qu'on fait et qu'on ne veut plus faire, et (3) ce qu'on ne fait pas et qu'on devrait faire. Cela doit être examiné en terme de valeur ajoutée apportée par chaque process, par chaque document. Certains sont cependant obligatoires ou légaux. Vous en tiendrez compte.

Automatisation, personnalisation et exposition API

Il est grand temps que l'ordinateur puisse être utilisé pour ce qu'il fait de mieux : des traitements automatiques.

Je suis consterné de voir que dans nombre d'organisations on s'adonne avec un plaisir non dissimulé ou avec un ennui fracassant à la joie du copier-coller.

J'ai vu une organisation qui payait un consultant externe au prix d'un Chef de projet senior pour copier-coller à longueur de journée des rapports de bugs de Word en Jira, puis pour copier-coller les intitulés de Jira en Excel. Ah certes, les colonnes avaient de belles couleurs, mais où diable est passée l'efficacité, où diable est passée la réflexion ? Ce consultant coûtait environ 20000 €/mois et personne ne s'est jamais dit qu'il vaudrait peut-être mieux dépenser cet argent à (1) former le business à utiliser Jira et (2) automatiser le rapport dont le Management avait besoin pour juger de l'état d'avancement factuel du projet (car enfin, si on utilise Jira, on peut aussi bénéficier de rapports automatiques à la demande !)

Nous sommes tous coupables de ces types de comportement, les uns à les produire, les autres à ne pas les dénoncer, ou à tout le moins à ne pas les mettre en lumière pour qu'une réflexion se fasse ! Automatiser est le maître mot. Tout ce qu'on peut ! Cela ne peut se faire que par des gens qui connaissent les outils à utiliser et qui peuvent en tirer la substantifique moelle. Vous avez besoin de … développeurs ! Automatiser est un levier de démultiplication de votre force de travail. Il est indispensable de développer un état d'esprit, un réflexe intellectuel, qui s'applique dans nombre de situations, pas uniquement limitées à la mise en place d'un PMO pourvoyeur de valeur !

Plus tard, je m'appesantirai sur l'exposition API qui dirige tout mon travail actuel en ce qui concerne OpenPMO, une initiative qui me permet d'illustrer par la pratique les éléments qui sont décrits et présentés ici, entièrement pilotée par appel API et donc … entièrement automatisable.

Notes de bas de page

[1] … Le site n'est pas encore actif. Je commencerai ce travail en y logeant un exemple factice qui nous en apprendra beaucoup sur les outils de visualisation que je préconise

[2] … On ne guérit jamais quelqu'un qui ne se sent pas malade : la prise de conscience du problème est une des étapes de la guérison

[3] … Nettoyage

[4] … À vrai dire, il ne faudrait pas parler de projets mais plutôt de fonctionnalités à développer (features). Je préfère pour ma part parler d'aspirations ce que je couvrirai à un autre moment plus opportun.

Telegram icon