Le chef de projet est mort, vive le chef de projet !

Les approches Agiles ne parlent généralement pas des chefs de projet alors qu’il s’agit d’un rôle que l’on retrouve dans un grand nombre d’entreprises qui utilisent ces démarches. Je suis certain qu’ils ne sont pas là pour faire de la figuration !

J’aimerais prendre le temps de réfléchir avec vous à la place du chef de projet dans une approche Agile. Imaginons que nous (l’ensemble des personnes impliquées directement dans le projet ainsi que la direction) nous posions la question suivante au moment de commencer chaque projet : « Pour ce que nous souhaitons réaliser ensemble, comment allons-nous nous organiser ? » Et ce, au lieu d’appliquer systématiquement le modèle habituel dans lequel chaque rôle est figé, et où chaque projet est inséré (parfois par la force) dans un cadre de gouvernance prédéfini.

Il devient alors assez évident d’énumérer ce qui doit (ou ce qui devra) être réalisé. Cette liste d’activités, qui va du suivi financier à la coordination avec les parties prenantes en passant par le découpage et l’affectation des tâches quotidiennes, le suivi des fournisseurs, la mise en production ou le soutien, etc. contient autant des éléments de fonctionnement internes qu’externes à l’équipe créée. Rien de nouveau jusqu’ici…

Plusieurs approches possibles

Maintenant, plusieurs choix s’offrent à nous. Une première approche est de nous questionner à propos des personnes qui vont accomplir chacune des activités nécessaires à la réussite du projet. Chacun ayant des compétences et des préférences différentes, et, espérons-le, complémentaires, toutes les activités devraient trouver preneur. Si ce n’est pas le cas, il manque peut-être quelqu’un dans l’équipe. Les participants peuvent se porter volontaires pour assumer les responsabilités associées. À noter qu’un atelier collectif de matrice de compétences peut aider dans cette situation.

Vous obtenez alors une organisation qui correspond à la réalité du contexte humain de votre projet. Des appellations nouvelles ou traditionnelles peuvent être utilisées pour nommer ou définir les activités de chacun. L’essentiel me semble être que tout ceci soit clarifié lors des conversations, puis mis en évidence de manière visible (une belle occasion d’introduire du management visuel).

Une autre approche associe les responsabilités définies dans des cadres tels que Scrum avec les différentes activités listées, puis répartit toutes les activités non prises en charge. Par exemple, en Scrum, le découpage et l’affectation du travail sont réalisés par l’équipe de développement. Vous pouvez assigner les activités non prises en charge par les rôles Scrum à l’équipe Scrum ou à des personnes extérieures à celle-ci. Un outil comme le Delegation Poker est très utile dans ce contexte.

À ce stade, vous devriez avoir une cartographie de départ, créée collectivement, des activités et des responsabilités qui vous mèneront, je l’espère, vers la réussite. N’oubliez pas qu’en Agilité, l’inspection et l’adaptation vous permettent de vous ajuster en cours de route !

Le chef de projet

Et le chef de projet dans tout cela, où est-il ? Je n’ai pas LA réponse à cette question. À ce stade, j’ai envie de savoir si en tant que personne impliquée, vous avez trouvé votre place au cours de l’exercice précédent ? Si oui, la question est résolue ! Si non, j’ai envie de vous poser les questions suivantes : « Au service de qui ? », « Au service de quoi ? », « Êtes-vous présent dans cette équipe ou cette entreprise ? »

Avec toutes ces questions, vous avez peut-être l’impression que je ne vous aide pas.

Votre entreprise est très structurée et chaque rôle est bien défini. Le vôtre est d’être chef de projet, alors que votre collègue est architecte ou analyste d’affaires (Business Analyst). Ce qui vous intéresse, c’est de savoir où est votre place maintenant que l’entreprise pratique l’Agilité. Mais peut-être que votre entreprise essaie de mettre des carrés dans des ronds…

Votre responsabilité est alors possiblement de remettre en question l’approche de votre entreprise ou votre approche personnelle. Beaucoup d’entre nous sont attachés à leurs rôles et à leurs statuts. Nous avons parfois l’impression qu’ils définissent notre identité dans l’entreprise. D’une certaine manière, c’est vrai ! Mais, d’un autre côté, ce n’est qu’une part de ce que nous sommes (certes importante, puisqu’elle occupe plus du tiers de notre vie.)

Je crois donc que la question devrait être : « Quelle est MA place dans une approche Agile ? » Et là, vous seul pouvez trouver la réponse…

Quelle est ma place?

Vous aurez compris que je vous invite à reconsidérer la question dans une perspective différente ; celle de l’exploration de la valeur que vous pouvez, en étant la personne que vous êtes, apporter à votre équipe ou à votre entreprise.

À titre d’exemple, j’ai pu observer des réponses très variées au cours de mes différentes expériences en clientèle. Les chefs de projets plutôt intéressés par l’aspect métier semblent avoir tendance à aller vers le rôle de Product Owner (PO) lorsque Scrum est utilisé. Ceux qui sont plutôt orientés vers les dynamiques humaines et les équipes semblent se plaire dans le rôle de Scrum Master. Enfin, certains restent chefs de projet, en mettant plutôt l’accent sur l’extérieur de l’équipe, sur la gestion des partenaires externes (fournisseurs et autres départements) et sur un soutien important au PO, par exemple en ce qui concerne les aspects financiers.

Je crois que vouloir copier-coller dans un contexte Agile les postes élaborés dans un contexte traditionnel et avec des contraintes de projet traditionnelles est une erreur. Cela ne prend pas en compte toute la complexité de la situation et surtout le fait qu’une transition Agile est un changement de paradigme. Que votre activité soit désignée sous le nom de chef de projet, pourquoi pas ! Il me semble cependant primordial que le périmètre soit revu et adapté au paradigme Agile.