Le PMO au service des équipes projets

Le grand public imagine souvent les informaticiens dans les grandes entreprises comme des espèces d’ingénieurs fous, des chevelus,… Il y en a, bien sûr, mais il y a aussi un tas de gens, comme la maitrise d’ouvrage qui assure les relations entre les informaticiens et les personnes « du métier », les intégrateurs, les chefs de projet,… Et il y a les « PMO », pour « Project Management Office ».

Si vous parlez anglais, vous aurez compris de quoi il s’agit. La page Wikipedia vous fournira plus d’information. Elle dit à juste titre qu’il ne faut pas confondre la notion avec celle de chef de projet mais que la confusion est courante (« chef de projet » est parfois « retraduit » en PMO pour « Project Management Officer » qui n’existe pas). Elle dit aussi qu’il y a plusieurs types de PMO : les PMO rattachés à une entreprise, une organisation, un projet,…

C’est une notion relativement récente. Plus exactement, c’est une appellation et une organisation récente. Auparavant, dans une entreprise, on avait des équipes en charge de l’organisation et des méthodes qui définissait des normes que les chefs de projets devaient appliquer pour leur gestion. Les méthodes se sont structurées, des référentiels se sont créés, au niveau international. Parallèlement, on s’est rendu compte que les méthodes étaient souvent mal appliquées d’une part parce qu’elles ne sont pas nécessairement adaptées à chaque projet et d’autre part parce que les chefs de projet ne les connaissent pas parce qu’ils ne peuvent pas tout connaître.

Je vais raconter une anecdote pour illustrer ce point. Quand j’étais consultant, j’avais été appelé par un client pour lancer un projet en respectant les méthodes de l’entreprise. Il me fallait faire des cahiers des charges pour des fournisseurs. J’en avais fait un billet : le cahier des charges est une des bases de l’informatique puisque qu’il permet de définir ce que l’on veut faire. J’ai cherché dans les méthodes internes à la société, je n’ai pas trouvé. Tous les documents étaient prévus pour circuler dans l’entreprise, avec les méthodes de l’entreprise : rien n’était destiné à des fournisseurs. Les lascars chargés des méthodes avaient oublié.

Dans cette mission, j’ai ainsi passé plus de temps à étudier les méthodes qu’à faire le cahier des charges en question. Un chef de projet n’a pas le temps : il doit faire sa gestion de projet, gérer ses équipes, avoir les compétences techniques, connaître l’organisation de l’entreprise,… Vous aurez beau organiser des formations : appliquer les méthodes officielles fait prendre trop de temps, ce qui ne veut pas dire que les méthodes ne sont pas utiles.

Globalement, dans les années 2000, en France, les équipes projets se sont dotées d’un « organisateur » chargé de mettre en place les outils adaptés et d’aider les informaticiens. Dans ma carrière, j’en ai connus des très bons, dont un qui s’appelait « facilitateur » ce qui résume très bien le job. On peut les appeler comme on veut, « organisateur », « ingénieur qualité »,… le rôle est le même.

Un exemple ?

D’accord. Pour bien comprendre l’organisation d’un projet informatique, le mieux est de partir d’un exemple. Imaginons le Directeur du Réseau d’Agences d’une banque. C’est le lascar qui aura en charge la gestion de toutes les agences et des conseillers clientèles. On lui remonte que les clients se plaignent de difficultés pour avoir un rendez-vous. Il décide donc de lancer un vaste projet pour que les clients puissent prendre rendez-vous sur le serveur web, l’application sur tablette et celle sur smartphone, le tout en relation avec l’application qui gère l’agenda des conseillers,…

Il va désigner un « chef de projet métier », dans ses équipes, qui aura pour mission de lancer cela et de faire la coordination entre les différents acteurs : l’informatique d’un côté et les différentes fonctions métier de l’autre (on ne sait pas trop qui peut être concerné mais comme ça touche à la relation client, il est probable que la direction marketing, la direction de la communication et la direction juridique soient concernés, sans parler de sa propre direction).

De son côté, le directeur informatique aura nommé un chef de projet, probablement dans le département qui gère les serveurs web et les applications smartphone et tablette. Il aurait pu le nommer aussi dans l’équipe en charge de gérer les applications utilisées par les conseillers puisqu’elles leur permettent de gérer leurs propres agendas. Il va y désigner un référent qui sera chargé de piloter le projet de son côté.

Nous avons donc trois lascars : le chef de projet métier (CPM), le chef de projet du côté de l’informatique (CP) et le référent de l’équipe « poste de travail en agence ».

Le CPM devra réaliser une expression de besoin. Cela semble facile : il faut permettre au client de prendre rendez-vous, mais c’est plus compliqué que ça, il faut définir des écrans, une infographie, gérer les cas d’erreur comme le client qui ne trouve pas un conseiller disponible à ses horaires et en tirant les fils, on trouve un tas de problème. Par exemple, un client aura un conseiller attitré. Il faut donc que le système qui sera mis en place trouve le conseiller d’un client qui fait la demande mais trouve aussi un remplaçant pour les vacances ou si les dates de rendez-vous sont incompatibles,… D’un truc que l’on pensait simple, on va se retrouver avec des dizaines de personnes concernées et une expression de besoin qui fera une bonne centaine de pages… Tiens ! Que fait-on des clients qui prennent des rendez-vous mais ne viennent pas ?

Nos trois lascars vont bosser ensemble, ou parallèlement, puisque les informaticiens devront faire les cahiers des charges pour leurs propres services tout en définissant comment le serveur qui gèrera l’application web et les applications tablette et smartphone puissent accéder au serveur qui gère les agendas.

Ensemble, ils vont déterminer un budget et un planning global avec des jalons. Par exemple, il faut que les services qui vont gérer l’agenda soient près avant les services qui vont gérer les pages web pour que ces derniers puissent y faire appel. Ils vont aussi prévoir la fin du projet : les homologations, le déploiement des nouveaux services,… Et l’intégration aux applications.

Tout cela est très important. Imaginez que l’application iPad soit prête avant tout le reste. On ne va pas la mettre sur l’iStore si les serveurs ne sont pas prêts…Mais les types qui développent l’application iPad ont d’autres évolutions sur le coude. On ne va pas bloquer les autres évolutions si on est en retard dans notre projet.

C’est alors que le directeur du département « multicanal » (celui qui fait que les opérations proposées sont accessibles à partir du poste en agence, des serveurs web,…) dit : « hé ho, les gars ! On ne va pas offrir un nouveau service s’il n’est pas disponible sur les distributeurs de billets. » Nous voila donc avec deux acteurs supplémentaires : le type qui s’occuper des distributeurs au siège et celui qui s’en occupe à l’informatique. Ces braves gens travaillent mais ce dernier dit : « hé ho, ce n’est pas moi qui fait les logiciels mais le constructeur de GAB ! » Il faut donc passer un contrat avec le constructeur. La direction des achats est donc concernée… Mais le type des GAB dit aussi : « hé ho, je n’ai pas que cela à foutre, la maintenance de XP s’arrête, il faut que je passe toutes mes machines à Windows 7, c’est un bordel, il faut qu’un technicien passe sur toutes. » Le type des achats dit alors : « hé hé ! On va tout négocier en même temps : le passage des techniciens, les licences Windows 7 et la nouvelle fonction de prise de rendez-vous. »

Voila comment on est passé d’un projet qui parait simple à un truc beaucoup plus compliqué et donc très cher, mélangé, lui-même, à des projets pharaoniques.

Nous avons donc nos trois acteurs initiaux : le chef de projet métier, le chef de projet informatique et le « référent ». Ils forment une belle équipe mais le chef de projet métier automates et le chef de projet informatique automates font partie de l’aventure, ainsi que le chef de projet métier serveur web, le chef de projet métier tablettes et smartphones, le chef de projet informatique serveur web, le chef de projet informatique tablettes et smartphones, le chef de projet métier automates et le chef de projet informatique automates, sans compter le type des achats. Le tout est sous la coupe d’un type des services juridiques, d’un de la direction marketing et un autre du commercial.

C’est le bordel. Nos trois décident de faire une réunion informelle tous les lundis matins à 10 heures. Ils vont appeler ça « point de synchronisation ». Il semble nécessaire de réunir tous les acteurs du paragraphe précédent tous les mardis matins. On va appeler ça le Comité projet. Leurs chefs qui sont dépassés par les événements voient bien que les lascars ont du mal à se mettre au point. Ils décident de faire un « comité de pilotage » tous les mois. Comme c’est un peu trop compliqué, les directeurs vont se voir tous les trois mois pour prendre les décisions. On va appeler ça le « comité stratégique ».

Vous croyiez que c’était simple, un projet informatique ? Et encore, je ne rentre pas dans la technique, je me limite aux aspects liés à l’organisation… Les gugusses du comité stratégique finissent par dire : « hé ho, vous nous cassez les burnes, nous allons nommer un directeur de projet. » Puis : « bon ben ça sera le chef de projet informatique puisqu’il a une cravate. »

Revenons au PMO…

Mon exemple n’est pas délirant. D’une part, j’ai complètement zappé la technique pure : les serveurs auront une charge d’activité supplémentaire ce qui doit être géré, par exemple. D’autre part, je n’ai pas chargé la barque. Par exemple, on trouverait bien un lascar qui décide d’envoyer un SMS au client 24 heures avant le rendez-vous. Ou un autre qui trouverait amusant de mettre à jour l’agenda Google du client…

Surtout, on voit bien que notre directeur de projet et ses deux compères seront rapidement débordés par toute cette organisation et n’auront plus le temps de faire leur travail courant et sa déclinaison dans le projet. Ce projet n’est pas lancé : le budget et le planning n’ont pas encore été sortis donc validés par les grands chefs pour déclencher les développements informatiques.

Si, en plus, le dirlo doit étudier les méthodes de gestion de projet de la maison, il coule. Il doit assurer la coordination, préparer des réunions, gérer les listes de tâches, des relevés d’actions, relire des documents, les valider, consolider les informations, en transmettre aux personnes concernées, répondre aux questions,…

Un jour, le chef de projet informatique, nommé directeur de projet, croise son directeur à la machine à café qui lui demande si tout va bien pour le projet. « ben, heu, c’est compliqué ». « Ah ! Passe me voir à 17 heures ».

Et ils s’expliquent… Le directeur comprend. Et il prend les mesures…

Et voila le PMO !

Le directeur va confier au bureau de gestion de projet certaines tâches, la première étant de définir, avec le directeur de projet, l’organisation du projet, comme les comités que j’ai évoqués ci-dessus, mais aussi tout ce qui va avec : la gestion de ces réunions, la préparation des supports, donc le reporting, la consolidation des plannings et des budgets, le suivi des actions,…

Basée sur les standards internationaux et les pratiques de l’entreprise, cette organisation et les méthodes qui en découlent sont adaptées au projet, aux acteurs concernés,…

Le PMO ne dépend pas hiérarchiquement du directeur de projet et n’a pas spécialement de compétences techniques ou métier. Il les acquerra au fur et à mesure puisqu’il devra présenter l’avancement du projet à la hiérarchie. Et comme il ne dépend pas hiérarchiquement du directeur de projet, il ne rentre pas dans le budget qu’il gère…

Une fonction nouvelle ?

Quand j’ai commencé à bosser, on n’avait presque rien. Progressivement, il y a eu une montée en charge des méthodes et outils qui nous ont bien envahi. Des départements « méthodes et organisation » se sont montés dans les grosses boites.

Elles sont devenues de plus en plus compliquées à adapter à chaque projet ou à chaque entité. Les équipes ont donc intégré des spécialistes, des consultants chargés de faire appliquer les méthodes (ça a été mon rôle à une époque). D’en d’autres cas, des services d’assistance aux équipes ont été mis en place.

Maintenant, nous avons la PMO qui gère les gros projets à la place des directeurs de projets, tout en adaptant les méthodes et l’organisation aux besoins réelles, sans être nécessairement intégrée à l’équipe.