Chef de projet IT : est-ce juste compter les absents ?

Chef d'orchestre et responsable du bon déroulement d'un projet IT, le chef de projet est le garant des coûts des délais et de la qualité. Il ne peut pourtant se contenter d'être un simple gestionnaire

Aujourd’hui, la plupart des chefs de projets informatiques sont des méthodologues. Ils deviennent les garants du suivi d’un processus et les exécutants d’une gouvernance, remplissant consciencieusement les tableaux de bord et autres plans d’actions avec une compréhension finalement assez faible sur le fond et les réelles implications. Or assurer une maîtrise des coûts, tenir les délais imposés, et être le garant d’une qualité de bon niveau demande bien plus qu’une simple gestion administrative… Le chef de projet n’est pas là pour juste compter les absents !

Un chef de projet doit avoir 4 coups d’avance et un large panel de compétences

Le propre d’un chef de projet est d’être capable d’échanger avec tous les parties prenantes d’un projet, que ce soit avec des équipes IT, des équipes métiers, la direction financière ou la direction générale pour les projets les plus stratégiques ou sensibles porteurs d’une transition profonde de l’entreprise.

Il est donc nécessaire pour le chef de projet d’être capable d’anticiper les problèmes, d’avoir une connaissance approfondie de la technique, lui permettant de challenger les différents acteurs sur les orientations techniques, sur les risques ou les points de blocage, de comprendre les implications pour la bonne marche du projet. Ce qui n’est pas clair pour un chef de projet est une menace potentielle qu’il doit mettre sous contrôle.

Ces 4 coups d’avance vont ainsi être nécessaires pour devancer les problèmes, identifier des solutions et les mettre en place. Le chef de projet est à l’avant du projet, et fait preuve de leadership pour réellement influer dessus. On attend d’un chef de projet non pas qu’il indique qu’il y a un problème, mais qu’il explique d’où vient le problème et comment le résoudre.

Au-delà de ces compétences techniques, d’anticipation et de leadership, la compréhension des organisations et des jeux de pouvoir est essentielle afin de faire levier sur les bons interlocuteurs et obtenir les bons arbitrages pour la bonne conduite du projet. Nous parlons bien ici d’une forme de diplomatie et de conscience des rapports de force à acquérir.

Enfin, un chef de projet ne peut se permettre d’être un mauvais communiquant, que ce soit pour emmener les parties prenantes, que pour communiquer de manière efficace en cas de gestion de crise.

Une profession qui s’est éloignée de la technique

Aujourd’hui, le profil des chefs de projet est un profil de gens intelligents, organisés et qui savent suivre à la lettre des méthodologies, tout en disposant de réelles compétences en matière de gestion.

Toutefois, en se focalisant sur ce type de compétences organisationnelles, ces profils se sont peu à peu détachés de l’aspect technique. Et c’est une partie du problème. N’avons-nous jamais entendu un chef de projet IT dire en comité projet : « vous savez, la technique je n’y comprends pas grand-chose, qui peut m’aider à rédiger le CR ? ». Sans parler de l’impact dévastateur sur sa crédibilité, le remisant ainsi au rang de scribe/secrétaire, il ne pourra pas comprendre les orientations, les risques et les enjeux. Son impact réel sur la bonne réussite du projet sera au mieux faible, voire inexistante. Il n’a pas à avoir le même niveau d’expertise que les contributeurs techniques, mais il doit être capable d’échanger avec eux, de comprendre les concepts qu’il manipule, un peu comme un scientifique qui est capable d’utiliser un théorème dans ses bonnes conditions d’application sans pour autant être capable de le redémontrer comme saurait le faire un mathématicien. Un bon chef de projet IT doit être un bon ingénieur (dans l’esprit, nous ne parlons pas forcément du diplôme).

Cela va permettre au chef de projet d’éviter de se faire « balader » par les équipes techniques. Par exemple, une équipe IT va indiquer que pour l’accomplissement d’une tâche, 5 jours seront nécessaires, alors qu’en fait 1 jour suffit, ou arguer d’un point de difficulté douteux (si si, ça arrive). Sans compréhension technique, le chef de projet pourra largement se faire abuser. Pouvoir dire aux équipes : « expliquez-moi pourquoi vous avez besoin de 5 jours et quel est ce point de blocage ? », comprendre si c’est légitime ou pas, permettra non seulement d’assoir sa crédibilité et dissuader que cela ne se reproduise, mais ça lui permettra également d’être force de proposition pour une éventuelle résolution ou une solution de contournement.

Les organisations IT sont assez fautives sur ce plan, en ne considérant pas ou peu les compétences techniques des chefs de projets qu’elles recrutent ou mobilisent, considérant qu’une tête bien faite et une posture de gestionnaire suffisent. De même que l’orientation vers une carrière de chef de projet a pu être choisie par manque d’appétence ou de compétences techniques après un cursus initial malgré tout orienté IT (et il faut bien avoir un boulot et manger).

Un enseignement incomplet donnant une idée réductrice du métier.

Si l’enseignement technique IT est plutôt de qualité dans les écoles d’ingénieurs, la réalité concernant la formation et les modules autour de la gestion de projet se concentre essentiellement sur l’aspect gestion en occultant un peu tout le reste, renforçant l’image d’un métier ou la technique importe peu et la gestion est reine.

De façon pragmatique, les étudiants ingénieurs apprennent dans ces cours à créer et utiliser des diagrammes de Gantt, à établir des plans de ressources, à faire de la coûtenance (contrôle de l’avancement par la consommation budgétaire) … Ne nous méprenons pas, c’est indispensable et fait partie de la boite à outils et des compétences nécessaires à un chef de projet. Mais ce n’est tout simplement pas suffisant, où sont les apprentissages sur la gouvernance et la communication projet, la compréhension des organisations et des forces en présence… Je n’ai pas appris les méthodes autour de la stratégie des alliés à l’école mais bien plus tard dans le monde professionnel, lors d’une formation générale sur le management, pour ne prendre que cet exemple.

Une disparition du chef de projet simple gestionnaire…

Il est assez intéressant de voir que le rôle du chef de projet à presque disparu dans les méthodologies agiles. En effet, les éléments clés de priorisation, de gestion des risques, et de coordinations ont été redistribués sur les Product Owner et autres techleads, qui portent déjà par ailleurs la responsabilité de la compréhension des enjeux métiers pour les premiers, et la compréhension des orientations et risques techniques.

Alors c’est un cas un peu extrême car ce sont des méthodes d’exécution à ressources constantes limitant de fait la complexité de la gestion de ressources. De même, l’organisation en mode produit limite normalement le niveau d’interdépendance avec d’autres équipes ou contributeurs.

Mais c’est intéressant de voir que dès que l’on simplifie un peu le besoin en gestion, les missions d’un chef de projet qui ont été conservées et redistribuées sont liés à toutes les autres missions qui incombent à un « vrai » Chef de projet, la gestion se faisant de manière collégiale encadré dans un processus bien défini.

En conclusion :

Un bon chef de projet doit disposer de compétences multiples. Être un bon gestionnaire est effectivement un des basiques de la profession mais il n’est pas suffisant. Le chef de projet doit s’y connaître en technique, être assez politique pour identifier les différentes parties prenantes et leurs sphères d’influence, disposer d’une bonne vision globale et surtout disposer d’un leadership affirmé... bref, tout le contraire de compter les absents...