Le PMO, siège incontournable de la bureaucratie en entreprise ou d'une exemplaire Agilité ?
Je partage dans ce billet un point de vue sur l'application des méthodes agiles au Bureau de Management de Projet, plus connu sous son acronyme anglophone de PMO - Project Management Office.
Pour commencer, je pense que si vous adoptez une approche totalement prédictive, digne des célèbres cycles en V ou en cascade - waterfall, vous feriez mieux de vous arrêter immédiatement. En effet, cela ne marchera probablement pas. Ces approches font l'assomption de base que vous savez parfaitement décrire dans les détails ce que vous voulez. Si cela fait déjà un petit moment que vous avez commencé à préparer ou lancer votre PMO (entre 6 mois et 2 ans) mais qu'il ne vous donne pas pleine satisfaction, ce billet est rédigé pour vous !
En effet, il est fréquent qu'après des débuts prometteurs, le PMO commence à avoir du mal à délivrer ses promesses et par là même perde de son pouvoir de séduction auprès du management exécutif et des managers de projets qu'il sert. Je ne saurais vous proposer de solutions clés en main dans ce billet mais ces quelques idées sauront je pense vous être utiles.
A travers cet article, je suggère de tirer le meilleur d'une approche de l'industrie du développement logiciel et l'appliquer au PMO. Je ne suis pas un expert Agile, mais je commence à en
être un utilisateur plus que régulier. Il y a plusieurs pratiques qui ont fait leurs preuves et que vous pouvez employer dès aujourd'hui pour construire et améliorer votre PMO.
Voici donc 4 principes d'une approche Agile que vous pouvez adopter pour construire un PMO Agile :
#1. Favorisez les itérations rapides
Les méthodologies agiles sont centrées sur des cycles courts qui produisent des livrables immédiatement démontrables aux clients utilisateurs voire utilisables en production. Dans le développement logiciel, le livrable est donc du code qui fonctionne.
Dans un PMO, ces livrables pourraient être un rapport, un processus, un formulaire, une méthode, une revue de risques ou bien une formation.
Prenez cet exemple : Votre projet au sein de votre organisation est de mettre en place un PMO avec une gouvernance de management et de suivi des projets en 3 mois.
- Avec une approche traditionnelle prédictive, « en cascade » ou « cycle en V »
Vous planifiez l'approche et la méthode, tous les formulaires à livrer, tous les rapports à produire, tous les processus à suivre et toutes les activités requises pour produire tout cela. Vous identifiez tous les projets qui entrent dans le périmètre du PMO. A la fin de cette planification, vous aurez un échéancier détaillé avec un diagramme de décomposition des tâches.
En admettant que tout cela puisse tenir en un trimestre, après ces 3 mois d'analyse et développement, si vous n'avez rencontré aucun problème et bien suivi le déroulement de ce projet, vous délivrez une liste de projets exhaustive, de nouvelles procédures, rapports, processus.
...et alors, chacun peut voir vos livrables.
Et alors, immanquablement, chacun vous demande des modifications souvent très pertinentes :
« Ce n'est pas ainsi que fonctionne le business », « Il manque cette donnée cruciale dans ce rapport », « le formulaire est trop complexe et nécessite trop de d'efforts de saisie », « mon projet n'a rien à faire dans ce PMO », « pourquoi mon projet n'est-il pas dans le périmètre du PMO ? » etc...
- Avec une approche Agile itérative
Vous commencez par une liste de quelques projets représentatifs qui entreront forcément dans le périmètre du PMO. Puis vous élaborez un rapport critique et simple, disons celui sur les projets en court, le tableau de bord des projets.
En 2 semaines, vous développez ce tableau et le montrez à vos commanditaires et aux futurs utilisateurs. Immédiatement, vous obtenez des réactions directes qui peuvent vous faire changer de direction, revoir certains aspects, ajouter certaines informations manquantes, alléger le formulaire de saisie des mises à jour...
Parce que vous n'avez investi qu'une petite quantité de travail (2 semaines), vous pouvez facilement ajuster le rapport réalisé et adapter le travail à venir pour mieux coller aux attentes.
En avançant dans les itérations suivantes, vous créez des livrables successifs visibles de tous et corrigez progressivement les productions pour créer seulement ce qui est nécessaire, de plus de valeur et en le livrant au plus tôt. Vous en profitez pour ajouter quelques projets à chaque itération.
3 mois plus tard, vous avez un livrable qui a déjà reçu l'aval des parties prenantes et qui est démontrable et même utilisable.
OK, il ne contient probablement pas tous les projets ni tous les livrables que vous auriez identifiés en méthode prédictive, mais il a mis en production les plus critiques, il commence déjà à être adopté par de nombreux projets et vous commencez donc à en recueillir les premiers bénéfices.
#2. Dotez-vous d'un Product Owner
Le propriétaire de produit (Product Owner) est un sponsor de projet puissance 10. Le chef de projet peut en effet rencontrer son sponsor une fois par semaine. Avec son équipe projet, il rencontre les parties prenantes critiques comme les utilisateurs et clients encore moins souvent car elles « ont un métier ».
Le Product Owner, à l'inverse, intègre totalement l'équipe projet de construction des livrables. Il/elle est impliqué(e) quotidiennement dans les priorisations, les choix, les réponses aux questions et les démonstrations de livrables intermédiaires à de vrais futurs utilisateurs qu'il/elle aide à choisir.
Conservons le même exemple de mise en place un PMO avec une gouvernance de management et de suivi des projets en 3 mois.
- Avec une approche traditionnelle prédictive, « en cascade » ou « cycle en V »
Vous rencontrez votre sponsor chaque 2 semaines (ce qui est déjà en soi un exploit) et les parties prenantes utilisateurs plutôt en avant-projet lors de la collecte des besoins. Puis, vous faites un état d'avancement par rapport au planning chaque mois. À la fin des trois mois, le sponsor et les utilisateurs voient enfin, si tout s'est bien enchainé sans aucun accroc, le produit fini.
...et alors, chacun apprécie/critique les résultats... « Ce n'est pas ce que je voulais dire », « J'ai oublié de vous signaler que... », « il y a trop d'infos dans ce rapport », « les critères de sélections et d'évaluation des projets ne sont pas les bons », ...
- Avec une approche Agile itérative
Le Product Owner répond chaque jour aux questions des développeurs de l'équipe projet. Il/elle fait partie des décisions quotidiennes qui entrent dans la construction des livrables du produit final. Quand le Product Owner voit quelque chose à changer, il/elle le communique immédiatement. Il/elle priorise les livrables du projet en fonction de leur valeur business, de leur apport à l'organisation et aux futurs clients utilisateurs. Il/elle précise les besoins au fil des démonstrations. Le Product Owner s'assure que le produit final réponde bien aux objectifs et attentes des parties prenantes.
Quand les livrables sont mis entre les mains des utilisateurs, il y a moins de surprises, l'effet tunnel de l'approche prédictive est éliminé. Le Product Owner a tout vu pendant le développement, a pu répondre aux questions de l'équipe projet et a pu demander des adaptations quand cela était nécessaire.
Retrouvez ici, les 2 derniers principes pour construire un PMO Agile, dans un second article.
