Le Project Management Office (PMO) a gagné en popularité dans le monde des affaires aujourd’hui. C’est pourquoi j’aimerais partager mon expérience au sujet de ce rôle qui s’est révélé être très utile dans mes projets, notamment en y assurant une valeur ajoutée, en renforçant la performance de l’équipe et en réaffirmant l’excellence des processus ainsi que l’alignement stratégique des projets avec les organisations.
Le rôle de PMO est souvent perçu comme une fonction administrative entrainant par exemple, la rédaction de rapports, de documents et la définition d’un budget afin de maintenir la gouvernance du projet. Cette vision est malheureusement exacte puisque le rôle de PMO s’inspire initialement des méthodologies traditionnelles, tel que le PMBOK (Project Management Body of Knowledge) qui a façonné son image.
Auparavant, seules les personnes très expérimentées travaillaient en tant que « PMO directif » car les objectifs comprenaient non seulement la supervision des projets mais aussi celle des programmes et portfolios. Cependant, avec l’évolution des besoins des entreprises, on assiste aujourd’hui à la nécessité de profils plus juniors afin d’assister les chefs de projet sur les tâches plus administratives sans prise de décisions majeures : ce rôle porte le nom de « PMO de soutien ». Cela explique les décisions des entreprises d’assigner parfois ce rôle à des personnes hautement expérimentées, dans d’autres cas à des personnes moins expérimentées, ou encore aux deux, en fonction des exigences du projet.
Mon point de départ en tant que PMO de style agile :
L’image d’un PMO traditionnel pourrait en décourager certains, en particulier dans une organisation agile. Une entreprise agile est souvent synonyme d’environnement flexible, disposé à accueillir le changement, tout en se basant sur un certain nombre de bonnes pratiques. Perçu comme un rôle bureaucratique et « non-agile », le PMO semble contredire le mode de penser agile. Pratiquant moi-même l’agilité professionnellement, je ne me voyais pas jouer le rôle de PMO dans un premier temps… jusqu’à ce que cette position me soit assignée sur certains projets.
J’ai profité de cette opportunité pour analyser ce rôle afin de mieux le comprendre et de pouvoir ajuster certains processus, dans la mesure du possible, afin d’aligner mes objectifs professionnels de consultante agile avec ceux de la mission. Je me suis alors demandé s’il était possible d’intégrer cette fonction « non agile » dans un projet agile et de définir un rôle « PMO agile » ? L’objectif était de trouver un bon équilibre entre l’environnement de l’organisation et les avantages que ce rôle doit fournir, afin de pouvoir me projeter sur ce poste. J’ai commencé par découper les responsabilités classiques de PMO tout en analysant comment il pourrait être possible d’y implémenter des techniques agiles. Le but étant d’améliorer la valeur ajoutée pour l’équipe et pour le projet.
Mes principales tâches de PMO étaient les suivantes :
• La création d’une structure pour organiser le flux de travail et le suivi des livrables par rapport au planning,
• L’organisation des réunions nécessaires pour toutes les parties prenantes et l’équipe,
• La documentation des rapports de référence (les supports de comité de pilotage, comptes rendus, plan d’actions, etc.),
• Le partage, avec les membres d’équipe, de la visibilité autour des tâches et des échéances de projets,
• La garantie de la bonne communication, de la performance de l’équipe et des processus de travail tout au long du projet.
Au lieu de me focaliser sur la procédure, j’ai remis en question l’intérêt de chacune de ces tâches afin d’en comprendre précisément les objectifs et commencer à changer certaines techniques tout en répondant aux mêmes besoins.
Méthode de travail et approche :
Un des aspects fondamentaux, dans l’implémentation d’une méthode de travail, réside dans la volonté de fournir une valeur ajoutée au client/métier et de contribuer ainsi au succès du projet. Cet objectif étant le point commun entre les approches traditionnelles et agiles, il est important de rester concentré sur la finalité et non sur le processus.
On entend souvent qu’être agile consiste non seulement à changer les méthodologies et à appliquer des techniques non traditionnelles, mais aussi à être flexible et ouvert aux changements. Il s’agit ici de la définition d’un état d’esprit visant à délivrer rapidement une vraie valeur à l’équipe, au projet et aux clients. Ce que j’apprécie dans les principes agiles est le fait de « ne jamais compromettre la qualité du travail » et l’idée « d’amélioration en continue ». Ces principes constituent les règles d’or qui doivent être implémentées dans l’équipe, quels que soient les rôles ou les approches de management que vous utilisez. Même si l’organisation, le rôle, ou l’environnement de travail n’est pas agile, il est tout de même possible d’implémenter le style agile.
Par où commencer :
Prenons pour exemple le Product Backlog et le Sprint Backlog, que nous utilisons pour planifier des tâches du projet, le flux de travail ou l’organigramme des tâches du projet (OTP) dans la méthode traditionnelle.
• Le Product Backlog permet aux chefs de projet de lister et de prioriser tous les travaux attendus sous la forme de User Story et les livrables au travers des Features, contenant les critères d’acceptation ainsi que la complexité des tâches.
• Le Sprint backlog est un moyen d’identifier comment livrer rapidement de la valeur et ce sur une période la plus courte possible. Puisque le cycle de vie agile est plus court que celui de l’approche classique, un sprint ou une itération de 2 à 4 semaines est utilisé et permet de vérifier régulièrement la progression du travail. Cette technique réduit les risques d’ignorer certaines tâches, en particulier dans les grands projets puisqu’il y a, en général, plus de composants complexes causant des risques par rapport aux projets de plus petite taille.
Pour donner de la visibilité au projet et avoir une communication efficace sur l’avancée du travail dans l’équipe, le tableau Scrum et tableau Kanban permettent d’afficher les travaux planifiés, en cours, et terminés durant les sprints. C’est sur la base du management visuel que des tableaux sont créés afin de fournir plusieurs types d’informations dans la salle de projet. Le suivi des travaux peut se faire rapidement via le Daily stand-up meeting, réunion de 15-30 minutes durant laquelle chaque personne de l’équipe communique précisément sur ce qu’il/elle a fait depuis le dernier daily, ce qu’il/elle fera, les problèmes rencontrés et l’avancée des tâches. Cette pratique permet non seulement de piloter le travail mais aussi de rappeler à l’équipe le planning et les échéances à venir. Avec ces outils et techniques, la majorité de responsabilités de PMO sont couvertes et accomplies de manière beaucoup plus agile.
Scrum master vs. PMO:
À ce stade, on pourrait s’interroger sur la différence entre un Scrum Master et un PMO, au vu des similitudes entre certaines tâches.
• Le Scrum Master est un facilitateur de cérémonies agiles, notamment celles permettant la planification, la rétrospective et la revue de sprint, sans oublier le Daily stand-up meeting. Il/Elle assure l’implémentation et le respect de la méthode Scrum au sein de l’équipe et accompagne la recherche de consensus par le biais de la collaboration, de retours fréquents ainsi que d’un engagement suffisant avec les autres parties prenantes.
•Le PMO, quant à lui, est responsable de la gouvernance stratégique du projet en renforçant les principes, les méthodologies, les outils et les techniques de gestion de projet que l’équipe doit suivre pour s’aligner sur les objectifs de l’entreprise.
En outre, l’une des tâches les plus courantes qui leur est souvent confiée est la création de rapports. Qu’elles soient « traditionnelles » ou « agiles », les équipes doivent produire et conserver (si nécéssaire) les documents essentiels au suivi des actions et du reste à faire.
Pour résumer, le PMO et le Scrum Master sont tous deux responsables du respect du processus de travail et des progrès de leurs équipes afin de pouvoir assurer une livraison réussie du produit à la fin d’une itération et ce, avec l’utilisation des normes de gestion de projet. Par conséquent, si l’organisation ou le PMO promeut un état d’esprit agile, les deux rôles sont quasi identiques car les principes agiles sont mis en œuvre dans les projets et les équipes.
Conclusion :
Les avantages des méthodologies agiles résident dans la possibilité de s’aligner rapidement avec les changements issus des demandes clients. A l’heure de l’instantanéité et de la réactivité, il s’agit d’un élément crucial pour toute entreprise et pour tout secteur d’activité. Plusieurs techniques agiles se sont développées autour de la volonté de fournir un travail qualifié rapidement et fréquemment pour répondre aux besoins des clients. Par conséquent, pour maintenir la compétitivité des entreprises, il convient de fournir rapidement de la valeur par le biais d’un projet, et ce dans un environnement en constant changement. Ainsi, la question du processus ou du « chemin » à adopter lors d’un projet est caduque. A l’inverse, il convient plutôt d’identifier comment utiliser l’agilité dans un projet afin d’accroître sa flexibilité et sa réactivité. C’est pourquoi, je préfère opter pour une approche mixte, mêlant les meilleures pratiques de gestion de projet traditionnelle ou agile, et ce avec pour objectif principal la réussite du projet. Cette combinaison d’agilité et de tradition est possible à condition de ne pas tomber dans les écueils d’une méthode rigide ni dans les préjugés attachés au rôle du PMO.
« Ne vous cantonnez pas aux stéréotypes du PMO en perdant de vue l’intérêt réel de ce rôle. Ne laissez pas ces clichés vous démotiver alors même que vous êtes des experts agiles, car les tâches du PMO peuvent être amenées de façon agile ».
REFERENCES :
Strategic priorities and PMO functions in project-based firms
The many benefits of an Agile PMO : What you should know
