PMO : L'erreur la plus répandue
Dans la quasi-totalité des entités PMO créés, un ver s'introduit lors de la phase de conception et neutralise son bon fonctionnement. L'identifier et l'éviter permet de partir du bon pied et de profiter pleinement d'une organisation PMO efficace et évolutif.
Malheureusement, cette erreur de conception n'est pas admise, voire ignorée volontairement pour satisfaire l'ego du responsable si le PMO représente pour lui un moyen d'avoir du pouvoir. Ce que je dis là n'est donc pas audible la plupart du temps, et peut susciter de vive réaction. Pour comprendre, reprenons les bases de la conception d'un PMO.
La création d'une entité PMO se fait souvent à l'initiative des dirigeants qui souhaitent contrôler un ensemble de projets. Sans vraiment donner de sens conscient au terme du P de PMO, il devient alors naturellement une gestion de portefeuille, ou une entité de contrôle d'un projet ou programme. Or le PMO peut être aussi une entité de soutien à la réussite des projets et de développement de la culture projet au sein de l'organisation. Implémenter ou développer un PMO existant consiste à mettre en place des fonctions sur un périmètre de projet.
Ces fonctions peuvent être par exemple :
mettre en place un outil de tableau de bord projet
mettre en place un outil de tableau de bord consolidé pour un ensemble de projets (visions un portefeuille de projets)
création d'un manuel de projet de base mis à disposition des chefs de projet
organiser des revues de projet avec le chef de projet afin de remplir le tableau de bord projet
organiser des revues de risques avec le chef de projet
vérifier que les éléments rentrés dans le tableau de bord projet sont exacts
vérifier que l'avancement du projet est en ligne avec la planification
etc...
Il existe un très grand nombre de fonctions que l'on peut implémenter dans un PMO et adresser ainsi un ou plusieurs périmètre projet sur lesquels ces fonctions seront déployées. Par exemple, sur les projets stratégie d'entreprise, on décide de mettre en place une fonction de revue de projet périodique avec le chef de projet sous la direction du PMO dans le but de déterminer des écarts et de faire des propositions au comité de pilotage. Sur un autre périmètre de projet moins important, on décide de créer et de mettre en place un manuel de projet avec des formations pour les chefs de projet. Donc, le PMO devient un ensemble de fonctions X un périmètre de projet. Si on répertorie l'ensemble des fonctions possibles dans un PMO, nous en avons un nombre infini. Il faudra en plus rajouter des fonctions de gouvernance du PMO (processus de création d'une fonction supplémentaire, processus de recrutement d'une ressource PMO supplémentaire, etc.) Dans tous les cas, on peut se rendre compte que le degré de responsabilité du PMO diffère suivant les fonctions mises en place. Ainsi, mettre en place un outil de planification et former les chefs de projet peut sont des activités de soutien et de développement de la culture projet au sein de l'entreprise en standardisant le processus de planification. Par contre, vérifier que le chef de projet a introduit les bonnes données dans le tableau de bord projet, ou vérifier les écarts entre l'avancement réel du projet et l'avancement planifié est une activité beaucoup plus contrôlant que de soutien. Si on regroupe l'ensemble des fonctions dans les différents types de PMO proposés sur le schéma ci-contre, nous aurons quasiment toujours des fonctions impliquant le PMO à différents niveaux de responsabilités, plus ou moins contrôlante, plus ou moins de soutien. Où est le ver ?
Le piège est dans l'implémentation au sein de la même entité de fonctions incompatibles en termes de responsabilité. Il ne peut y avoir au sein de la même entité une fonction de soutien et une fonction de contrôle à partir d'un certain niveau d'implication du PMO. Pourquoi ? Parce qu'avoir vis-à-vis de la même personne (par exemple le chef de projet) un rôle de soutien et un rôle de contrôle entraîne une confusion des rôles qui fait que le chef de projet n'aura pas confiance dans le PMO.
Il y a alors rupture de confiance entre le chef de projet et le PMO :
Qui es-tu par rapport à moi ?
Es tu là pour m'aider ou pour me contrôler et me sanctionner ?
Il existe des rôles incompatibles suivant la règle de la ségrégation des devoirs. Il est essentiel dans une activité de soutien que le chef de projet puisse avoir complètement confiance en son soutien afin de lui transmettre toutes les informations dans une relation franche, directe et transparente, nécessaire aux mécanismes d'apprentissage et de collaboration. Si le chef de projet est en relation par contre avec une personne qui est là pour le contrôler, éventuellement le sanctionner, il va mettre en place des défenses naturelles contraires à la relation qu'il aurait si ce dernier était là pour le soutenir. Il existe donc une limite dans la responsabilité du PMO qui va caractériser cette incompatibilité de fonctions. Je regroupe donc l'ensemble des fonctions d'un PMO en 3 groupes :
les fonctions de soutien,
les fonctions de contrôles passifs,
les fonctions de contrôle actifs.
Remarques sur le schéma ci-dessus : Les fonctions grisées sont des fonctions de soutien ou de contrôle passif, et les fonctions en blanc sont des fonctions de contrôle actif.
N'oublions d'ailleurs pas il n'est pas question d'implémenter un type de PMO, mais d'implémenter un PMO qui peut regrouper des fonctions de plusieurs types. Où se trouve l'incompatibilité ? On ne peut avoir une fonction de contrôle actif vis-à-vis d'une personne que l'on souhaite soutenir, sans faire obstacle à la confiance nécessaire au bon développement de la culture projet. La limite exacte se trouve dans la vérification par le PMO de l'information transmise par le chef de projet. Ainsi, si le PMO met en place un outil de gestion portefeuille en poussant le chef de projet à alimenter les données sans que le PMO vérifient ces mêmes données, nous sommes dans une fonction de contrôle passif. Par contre, si le PMO vérifie les données, si elles sont exactes, on rentre dans un domaine où la fonction devient une fonction de contrôle active. Au sein d'une même entité, les fonctions de soutien une fonction de contrôle passif peuvent se côtoyer, mais sans y introduire une fonction de contrôle active. Ceci a de lourdes conséquences Dans l'organisation des différentes entités regroupant PMO et gestion de portefeuille, ou centre d'excellence, ceci dépendant des noms que l'on décide d'utiliser. C'est pourquoi il est important d'avoir un glossaire d'entreprise afin que tout le monde soit synchronisé sur l'utilisation du vocabulaire. Cela veut dire que dès la conception du PMO, il est nécessaire de faire une planification de l'ensemble des fonctions qui seront implémentées et de séparer ces fonctions dans des entités différentes en respectant cette règle. En général, il est tout à fait raisonnable de concevoir une entité de gestion portefeuille regroupant des fonctions de contrôle active, et un PMO de soutien, entités différentes, regroupant des fonctions passives de gestion de portefeuille associé par exemple avec des fonctions de soutien. Il est tout à fait raisonnable d'avoir donc plusieurs entités de gestion portefeuille (reportant chacune à des équipes dirigeantes différentes) et un ou plusieurs PMO de soutien regroupant des fonctions de soutien avec des fonctions de contrôles passifs. Si on reprend l'ensemble des exemples de fonction donnée ci-dessus, on se rend compte qu'il existe des fonctions de soutien (3), des fonctions de contrôles passifs (1,2,4,5) et des fonctions de contrôle actif (6,7). Attention à ne pas franchir la limite dans la définition de la fonction. Par exemple, organiser des revues de projet avec le chef de projet pour remplir le tableau de bord projet, consistera à inciter le chef de projet à récolter ces données, sans les vérifier, pour qu'il alimente le tableau de bord en temps voulu, sans se faire d'erreur sur le report des données. On est bien dans une activité de soutien pour alimenter une fonction de contrôle.
