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.
