Aujourd’hui je propose une réflexion autour du rôle de PMO qui est très populaire dans les grands groupes mais peu populaire dans la communauté agile.
PMO (Project Management Office) – definition
Le Project Management Office est un concept venant des pays anglo-saxon que nous appelons généralement PMO dans le monde francophone. Ce terme date des années 1950 mais le rôle a peu à peu évolué.
Le rôle est en réalité plus complexe à définir qu’il n’y parait car il varie selon les structures et les pays. Certains PMO participent au management de projets stratégiques, d’autres sont liés à une entité spécifique voire dédié à un programme spécifique d’une entité ; et le domaine d’application change logiquement les attentes que nous avons du PMO.
Voilà ainsi dans les grandes lignes ce qu’ils doivent faire :
- organisation d’un projet
- surveillance de l’état d’avancement de projets
- prise de décision stratégique (pour ceux lié à un portfolio)
- pilotage du portfolio (dans certains cas)
N’allons pas plus loin sur ce rôle, ce n’est pas le sujet de cet article.
Et en agile alors ?
Et ba le rôle de PMO a souvent persister dans les entreprises tentant de faire une transformation agile ; ce rôle est parfois même conseillé par les entreprises de conseil. Mais qu’en est-il ?
SAFe considère lui aussi l’importance du PMO
SAFe qui est le framework le plus populaire des grands groupes, considère que ce concept est essentiel au niveau du portfolio. Pour faire bien, il le nomme APMO (Agile Project Management Office).
Bon, SAFe n’est pas un représentant de l’agilité ! Une grande partie de la communauté agile le rejète car il n’est pas considéré comme Agile.
Le Framing Agile ne reconnait pas ce rôle
Le framing agile qui peut se mettre à l’échelle, lui n’opte pas cette notion de PMO mais cependant propose un concept qui pourrait s’y approcher.
Le Framing Agile propose la mise en place du Ministry qui va :
- travailler sur la priorisation du portfolio
- gérer les ressources nécessaires aux différents lancements
- gérer les éventuels besoins des produits
Le Ministry lui ne gèrera pas l’état d’avancement des produits. Chaque produit à son budget, son timing et ses ressources totalement alloués, il sera donc du ressort de l’équipe du framing agile de gérer cette partie là ; et cela indépendamment du Ministry.
Si l’équipe qui réalise le produit a une nécessité d’obtenir un budget supplémentaire validé par le Decision Committee de ce produit (indépendant du Ministry), il remontra l’information pour que le Ministry s’adapte à la situation.
Donc bien que le Ministry gère le portfolio, il a un rôle qui laisse beaucoup plus d’autonomie aux produits.
Et le PMO sur un projet scrum ?
Peut-on avoir un PMO sur un projet scrum ? Si beaucoup semblent dire que c’est idiot, il y a pourtant une partie oubliée par 90% des équipes scrum ; cependant c’est un aspect d’autonomie que peu d’entreprises veulent donner aux équipes.
Voici une partie importante du scrum guide sur la sprint review :
La revue des délais, budget, fonctionnalités potentielles et conditions de marché pour les prochaines versions prévues de la fonctionnalité du produit.
En effet, l’équipe scrum et les stakeholders doivent ensemble gérer le budget. Cependant rien n’interdit dans l’équipe de réalisation d’avoir une compétence PMO (celui associé à un projet) dans l’équipe de développement. Sur des projets complexes ou le budget est essentiel à gérer, ça ne serait pas forcément un non-sens.
Cependant, que ce rôle soit inclue dans l’équipe ou en transverse, il ne faut le mettre que si il n’alourdit pas inutilement le processus. Dans de nombreux produits, il ne sera pas nécessaire d’avoir un PMO.
Soyez le premier à commenter