21 February 2019

J'ai longtemps hésité avant d'écrire ce billet. En effet, à quoi bon passer une journée à écrire un texte qui va enfoncer des portes ouvertes ? Tout le monde sait que le chef de projet est important, pourquoi ce choix serait-il plus important ou différent lors d'une migration vers le cloud ? Qu'est-ce qui peut bien différencier un tel projet de migration d'un autre projet ? Alors j'ai repoussé. Mais le sujet ne me laissait pas en paix : en tant que spécialiste de la migration de data center, je sais que ce ne sont pas des projets ordinaires. Les enjeux sont à la mesure des risques : énormes ! En tant que directeur des opérations, mais aussi en tant que responsable d'équipes d'ingénieurs dans des sociétés de service, je connais les qualités à rechercher dans la bonne personne. Et en tant que chef de projet professionnel, je connais les défis qui nous attendent dans les projets. Enfin, en tant que spécialiste du cloud, je sais quels sont les enjeux techniques et humains, les difficultés, les pièges qui attendent sagement de se refermer sur le chef de projet... Alors je me dis qu'avec ces multiples points de vue et ces expériences, je me dois de prévenir le voyageur qui s'engage sur le chemin du cloud : pour assurer le succès de cette aventure, prenez garde au choix du chef de projet !

Tout d'abord, pour comprendre les enjeux, un petit mot sur le rôle du chef de projet.

Tout cela a l'air bien académique...Dans le concret, il :

• définit les livrables et les étapes pour y parvenir, de manière itérative, au fur et à mesure que la compréhension du projet mûrit,
• défriche le chemin, résolvant les problèmes, faisant émerger les solutions,
• identifie et implique les ressources, les orchestrant et les organisant dans le temps,
• et communique sur l'avancée du projet, les difficultés et les obstacles rencontrés, s'attachant à obtenir le soutien du management comme des équipes.

On entend souvent dire que le chef de projet est le chef d'orchestre du projet, mais cette analogie rapide masque les nombreuses qualités qu'il doit posséder :

Avant tout, le chef de projet doit être tendu vers la résolution de problèmes. Il doit faire preuve de ténacité pour ne pas s'arrêter au 1er obstacle, et de créativité pour contourner des obstacles qu'il n'aurait pas pu imaginer même dans ses cauchemars rêves les plus fous. Dans cette catégorie des obstacles improbables, je me suis trouvé confronté, lors d'un projet en Finlande, à l'obstination des autorités finlandaises qui refusaient de laisser entrer des équipements achetés en Europe et ayant transité par la Suisse pour y être configurés par mes équipes. Les douanes réclamaient la modique somme de 200'000 euros de TVA pour les laisser passer. J'avais alors des ingénieurs en vol à destination de cinq villes en Finlande pour un déploiement coordonné. Que faire ? Je n'avais pas le temps de remonter le problème à mon client par la voie normale. Je n'avais pas le temps non plus de demander une rallonge de budget en comité de projet (200'000 euros !), qui aurait pris des semaines à être validée. Je devais avoir l'argent dans la journée pour ne pas faire capoter le projet. J'ai donc pris l'initiative d'appeler moi-même le CFO de mon client en Italie. Je vous laisse imaginer le barrage de secrétaires et assistants et les négociations en franco-anglo-italien pour enfin accéder au grand patron...à qui il a fallu expliquer l'urgence et la réalité du problème. Bref, 24 heures plus tard, les douanes avaient leurs sous et moi mes équipements (oui, aussi avec 24h de retard...). Pour ceux qui s'inquiètent, le projet a été un succès, mais j'ai encore plein d'autres histoires à raconter sur la Finlande. Je vous les garde pour d'autres billets (j'aime bien raconter des histoires, même si ça fait un peu "ancien combattant").

Le chef de projet doit aussi avoir une vue d'ensemble du projet. Ne prenez pas votre spécialiste du stockage, ou du réseau, ou de ... : sa spécialisation le placera dans un tunnel qui le privera de sa vision périphérique. Il va se concentrer sur son aire d'expertise et négliger les autres aspects. Et comme on l'a choisit car il est le spécialiste de ceci ou cela, cela renforcera sa croyance que seul son domaine est vraiment important pour la migration. Ne cherchez pas non plus à avoir un spécialiste de tout, ça n'existe pas. Bon généraliste, le chef de projet doit être capable de comprendre la complexité, la difficulté et les enjeux de toutes les parties du projet. Les Américains ont une expression pour cela : "a mile large, an inch deep", ce qui signifie que le chef de projet doit savoir un petit peu sur beaucoup de choses, avec juste assez de profondeur pour comprendre les enjeux, mais très large pour garder une vision d'ensemble.

Il doit aussi être capable de gérer l'incertitude du projet. Cette qualité est importante et n'est pas donnée à tout le monde. On peut basiquement séparer les gens en deux catégories : ceux qui sont à l'aise avec l'inconnu, la nouveauté, qui apprécient de se lever chaque jour pour travailler à l'atteinte d'un objectif, sans savoir comment ils passeront leur journée. Ces sont les gens faits pour les projets. Et ceux qui préfèrent les périmètres délimités, les tâches connues, et savoir à quoi ils passeront leur journée. Ce sont les gens faits pour les opérations. Il n'y a pas d'opposition entre les deux, ce sont deux modes de fonctionnement différents et nous avons besoin des deux. Mais pour gérer un projet, il ne faut pas se tromper et l'assigner à quelqu'un qui préfère le mode "opérations". Cela semble simple, mais combien de projets ont fini dans les mauvaises mains, faisant le malheur de ceux qui en héritaient !

Le chef de projet doit aussi être un leader. Je préfère le titre anglais de "project manager" à "chef de projet" parce qu'il fait apparaître la dimension managériale. En effet, le chef de projet est avant tout un manager, un leader dont la matière de travail est l'humain. Ce n'est pas lui qui réalise le projet: il le fait faire par d'autres. Il lui faut constituer une équipe de gens qui ne lui répondent pas directement, qui ne l'attendaient pas pour travailler, qui ont d'ailleurs plein d'autres choses à faire et à qui ont rajoute des tâches dans le cadre de ce projet géré par un autre. Et souvent, c'est un externe "qui ne connait pas la boite", qui ne connait pas les applications, et qui ne connait pas l'infrastructure. Et qui n'est un expert de rien, en plus ! C'est dans ce contexte souvent hostile que le chef de projet doit mobiliser des ressources, leur transmettre sa vision du projet et déléguer les tâches pour concrétiser cette vision. Ajoutez là-dessus les moyens parfois limités, les délais courts, les mauvaises volontés et vous arrivez à une situation où la compétence principale que l'on demande au chef de projet n'est pas de connaitre telle ou telle technologie mais de faire preuve d'un vrai leadership !

Oui, je vous entends : tout cela s'applique à tous les chefs de projets, quelque soit le projet, rien de nouveau. Et on finit toujours par s'en sortir, avec plus ou moins de succès sur les 3 versants du triangle "budget, délai, qualité". Et vous avez raison. Mais un projet cloud présente quelques spécificités qui méritent de prêter un peu plus d'attention à la sélection du chef de projet.

Tout d'abord, c'est un projet à fort enjeu. Et ce n'est rien de le dire ! Pour le mesurer, imaginez un seul instant que quelque chose se passe mal et que votre entreprise soit privée de son informatique pendant quelques heures. Ça fait mal ? Bon, maintenant imaginez qu'elle en soit privée pendant quelques jours...ou plus. Alors ? Nous sommes donc d'accord, il y a de l'enjeu. Lorsque j'ai déménagé il y a quelques années un grand data center bancaire, je n'avais qu'une seule directive : pas UNE SEULE seconde d'interruption des services. Au moins, c'était clair...

C'est aussi un projet d'innovation. Vos équipes ne l'ont encore jamais fait auparavant, ils sont confrontés à de nouveaux outils, de nouvelles façons de faire souvent complètement inconnues et qui remettent en question leur façon d'exercer leurs métiers. Ce qui nous amène à l'enjeu humain d'un tel projet: attendez-vous au moins à des gestes de mauvaise humeur, à des réticences souvent et même à des tentatives pour torpiller le projet. Le chef de projet devra avoir à la fois le tact et la force de remporter l'adhésion d'équipes qui vont se sentir menacées par la nature même du projet, qui auront de la difficulté à penser leur métier différemment, à s'adapter, à se créer une nouvelle culture. C'est sur ce terreau que le chef de projet devra construire une nouvelle compétence au fur et à mesure de l'avancée du projet, compétence qui à son tour alimentera le projet et qu'il faudra partager, intégrer et peut-être faire venir de l'extérieur, ce qui alimentera encore le sentiment d'inadéquation des équipes et leur sentiment de danger face au cloud.

Enfin, un projet de migration vers le cloud est un projet risqué du point de vue technologique. Votre chef de projet risque de découvrir des équipements qui ne peuvent migrer (j'ai découvert un jour dans un data center un vieil HP9000 de 25 ans...allez donc migrer cela !), les équipes tâtonneront au moment de repenser l'architecture de l'infrastructure pour le cloud et feront face à des problèmes de performance lorsqu'il s'agira de migrer les données. Il faudra tenir la barre de façon ferme et garder la motivation des équipes dans ces moments de tourmente.

C'est la grande question. Nous savons qu'il doit être un bon généraliste, doué de leadership, et qu'il faut éviter un profile "opérations". Reste la question : interne ou externe ?

Prendre un membre de l'équipe interne présente l'avantage d'avoir quelqu'un qui connait l'entreprise, ses gens, sa culture et son métier. Mais s'il est issu d'une équipe technique et non d'un groupe de chefs de projets, il aura de la difficulté à établir son autorité sur les autres, surtout s'il y a une différence de séniorité dans l'équipe.
Il risque aussi de faire preuve d'un biais envers son équipe d'origine en établissant peut-être moins de contrôle, en mettant moins de pression pour obtenir ses livrables, ce qui pourrait placer le projet dans une situation délicate. Ce biais pourrait être volontaire, mais aussi inconscient ou être le produit d'une pression du groupe.
Enfin, comme toujours lorsqu'un interne est choisi pour un projet, la tentation est grande de le lui confier en plus de ses tâches existantes. Pas sûr que ce soit la bonne approche pour un projet de cette ampleur.

Prendre un chef de projet externe permet d'avoir une ressource neutre, disponible et disposant du bon profile. Mais il lui faudra un peu de temps pour installer son autorité et apprendre à connaitre l'entreprise, ses rouages et ses gens. N'ayez pas peur qu'il ne connaisse pas vos applications développées en interne, ou la façon dont vos infrastructures sont construites. Sans vouloir vous faire offense, ce n'est pas pertinent pour le chef de projet. Il trouvera ceux qui savent.