Management de projet IT : pourquoi vous devriez passer au flux !

Retour vingt ans en arrière, lorsque, en tant que chef de projet, influencé par le lean et l’agilité, je pilotais des centres de services pour des grands groupes du tertiaire financier. Un retour en arrière utile pour mettre en avant les avantages d’un pilotage de vos activités par les flux plutôt qu’en mode gestion de portefeuille, et pour montrer que si les sprints agiles sont une réponse à l’effet tunnel des gros projets en cycle en V, ils ne sont pas la seule réponse possible.

La maintenance applicative, une bonne école

Alors qu’un projet a des objectifs, des délais et un budget fixé, la maintenance applicative, elle, assure le maintien en conditions opérationnelles de l’application. Nous savons tous que la vie d’une application n’est pas terminée avec sa mise en production : bugs, évolutions réglementaires et fonctionnelles seront légions durant des années. Mais nous ne savons ni quoi, ni quand. Et c’est tant mieux ! Cela nous oblige à rester pragmatiques, ouverts aux changements, à être concentrés sur le présent et à résoudre des problèmes. Nous intégrons le flux de demandes comme il vient parce que nous sommes en prise directe avec les clients.

Ces contraintes nous ont permis de développer des techniques et des outils de pilotage adaptés à cette situation de flux continu de demandes. Notamment en termes de planification. Plus de planning sous MS Project, mais un plan d’activité mis à jour en permanence, avec toute l’équipe. Un plan adapté au quotidien, au rythme des changements imposés par le client et en fonction de l’avancement réel de nos travaux. Nous étions alors beaucoup plus agiles que certaines équipes flaguées “agiles”. Nous étions en capacité d’absorber les changements quand ils arrivaient. Au quotidien, et non toutes les 2, 3 ou 4 semaines selon la taille d’un sprint.

Le secret : Piloter le flux plutôt que gérer un portefeuille de demandes

Piloter le flux des demandes en temps réel s’est avéré la seule façon viable de travailler à peu près sereinement. Cela peut paraître paradoxal : gagner en sérénité en acceptant tous les changements qui arrivent, quand ils arrivent. En fait, l’idée que le changement permanent empêche d’avancer régulièrement est une vision restrictive. Je n’ai que rarement dû arrêter des travaux en cours. Parce que, justement, les sujets sont de taille assez faible, ce qui évite d’immobiliser tout le monde plusieurs semaines. Les spécifications sont assez facilement verrouillées sur ces “petits” sujets et les changements de priorité concernent essentiellement des sujets à venir, et non en cours. Finalement, ce ne sont pas les changements qui déstabilisent et génèrent du stress, c’est la façon de les intégrer qui peut en être à l’origine. 

Mais comment piloter un flux ? Il faut passer du traitement par lot (la version annuelle du SI, le sprint agile) à un traitement unitaire des demandes, au fil de l’eau. C’est là que notre plan d’activité prend toute son importance.

Identifier les étapes de fabrication

Le plan d’activité est découpé en colonnes qui représentent l’ensemble des étapes du processus de fabrication. Par exemple (de façon simpliste) :

• Demandes reçues
• Analyse de la demande
• Estimation de l’effort
• Réalisation des développements
• Non régression et tests métiers
• Déploiement en production

Chaque étape est représentée par une colonne, de la gauche vers la droite. L’objectif étant que les demandes traversent ces colonnes à la bonne vitesse, en respectant les urgences des clients. Piloter le flux des demandes revient donc à déplacer les demandes dans ce tableau en recherchant en permanence l’équilibre entre délai de fabrication (la vitesse), capacité à faire (combien de demandes dans une colonne) et priorités clients (quelle demande dois-je faire avancer ?). Les demandes se déplacent de la gauche vers la droite, mais c’est par la droite (qu’est-ce qui est attendu par le client) que l’on cherche tous les jours ce qui doit avancer.

Identifier les produits et les mixer

Le plan d’activité est aussi découpé en plusieurs compartiments horizontaux, suivant la nature des travaux et le niveau de prédictibilité de ceux-ci. Par exemple, nous savons que nous devons globalement affecter telle capacité à la correction d’incident, telle autre au support utilisateur. Ensuite, viennent les évolutions du système demandées par les utilisateurs ainsi que les sujets préventifs identifiés via l’amélioration continue. C’est souvent là que la demande est la plus variable et la plus difficile à anticiper. Enfin, les évolutions un peu lourdes ont l’avantage d’arriver avec un budget dédié, ce qui nous permet d’adapter la taille de l’équipe, si besoin. Nous avons une belle visibilité sur 2 à 3 semaines, moyenne jusqu’à deux mois, et franchement aléatoire au-delà. Mais ce n’est pas un problème puisque, grâce au flux continu des demandes, les zones de visibilité se déplacent avec le temps. Et faire plus relèverait de la boule de cristal.

Du flux en mode projet ?

Quand, sur un projet important (en taille), vous demandez à votre Product Owner de découper ses énormes besoins métiers en petites user story, que faites-vous ? Vous décomposez une complexité en éléments manipulables par l’équipe. Et c’est à ce moment-là que vous êtes en rupture avec le cycle en V, quand vous décidez de travailler par morceaux. L’énorme rocher est devenu un tas de petits cailloux (cf livre de Jeff Patton “Le story mapping”). Des cailloux plus ou moins définis, de taille et d’importance métier variable. Un tas de cailloux à même d’évoluer en fonction des boucles d’apprentissage du client, des difficultés techniques rencontrées ou de pleins d’autres raisons, bonnes ou mauvaises. Y compris pour prendre en compte d’éventuels bugs qui auraient échappé à votre perspicacité.

Contrairement à ce que nous pensons souvent, projets et maintenance applicative ne sont pas si éloignés. Le vrai problème ne réside pas dans le cycle en V en lui-même, mais bien dans le fait de l’appliquer à des projets pharaoniques. Ce qu’il faut combattre, ce sont les énormes projets à spécifications monolithiques, rêvées exhaustives qui imposent des effets tunnels y compris dans les développements, les tests et les déploiements. Là, l’agilité prend toute sa dimension et nous permet de changer de paradigme en revenant à des demandes d’une taille assimilable. Dès lors, comme en maintenance applicative, la mise en place d’un flux devient possible.

Se mettre au rythme du client

Travailler en flux avec des déploiements au fil de l’eau, dès que la fonctionnalité est prête, permet de se mettre au rythme du client. Plus de contraintes artificielles liée à une organisation en silos ou en sprints. Des règles partagées intégrant uniquement les contraintes et les opportunités opérationnelles des uns et des autres.

Le flux va permettre d’aligner l’ensemble des acteurs projets vers un seul but : se mettre au rythme du client et lui fournir la valeur qu’il attend. Mais il est exigeant : il nécessite une réelle ouverture des uns vers les autres ainsi qu’une forte capacité à accepter les changements. Tous. Quand ils se présentent, pas quand on aura le temps.

Simplifier la coordination

La mise en flux de la production de valeur permet aussi de coordonner plus facilement les dépendances. Chaque équipe projet ayant la souplesse d’intégrer très rapidement toute demande client, il n’est plus nécessaire d’essayer de synchroniser leurs plannings et de figer les périmètres de fonctionnalité sur 3 mois, voire plus. Si un produit A a besoin d’une fonctionnalité à venir d’un produit B, cela pourra se résoudre directement entre représentants clients. Chaque demande intégrera son flux et sera traitée, le plus naturellement du monde. La synchronisation redevient locale, en fonction des besoins réels et ce sont les clients qui décident.