Je vous l’avez promis il y a peu, voici le premier opus de mon feuilleton “en finir avec…”. Ma victime du jour est la roadmap.

Avant que vous commenciez cette lecture, un mot d’avertissement. J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.

C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !

La roadmap qu’est-ce que c’est ?

Ce terme est utilisé en informatique de manière assez libérale. Il peut concerne aussi bien un projet, qu’un ensemble de projet, une stratégie business et beaucoup d’autres choses encore. Je vais m’intéresser ici à la roadmap d’une organisation de développement. Elle est souvent relative à un portefeuille de projets, comme on le verra.

Mais au fond, que va-t-on attendre d’une roadmap ? Ou du moins, qu’est-ce que moi, je vais en attendre ?

Principalement une certaine perspective d’avenir, capable de me montrer les orientations des mois à venir. Je suis réaliste, je sais bien que :

• Plus on se projette dans le futur, plus le niveau d’incertitude est élevé. En un an, beaucoup de choses peuvent se passer en terme d’évolution du marché, d’opportunités business, etc… Je considère même que c’est un signe de bonne santé de l’entreprise, du moins tant que l’on ne confond pas évolution de la stratégie et atermoiement.
• Qu’un changement majeur de stratégie (un “pivot” dans le langage Lean Startup) peut totalement remettre en cause cette perspective à un moment donné.
• Qu’il n’est ni utile ni raisonnable de chercher à étoffer cette projection de détails que l’on n’a pas encore et qui seront peut-être obsolètes au moment où l’on traitera le sujet.

Bref, quand on va me parler de roadmap, je vais penser à quelque chose comme cela

En clair : une direction, avec des jalons représentant des niveaux d’accomplissements, mais aussi des dates en dur représentant des contraintes opérationnelles : engagements divers contractualisés, salons, etc…

Le syndrome de la roadmap de projets

Dans les faits, nous allons plutôt devoir composer avec un plan établi sur la base d’une liste de projets priorisés et planifiés en fonction de notre capacité de travail afin d’optimiser celle-ci en l’utilisant au mieux.

Peut-être aurez-vous remarqué le début d’une pointe d’ironie ?

Peut-être aussi, si vous avez suivi des posts et présentations plus anciens que j’ai pu faire, vous dites-vous que j’ai défendu ce même concept de roadmap il n’y a pas si longtemps ? Je l’avoue dès maintenant : mes idées ont sinon changé, du moins pas mal évolué. J’assume.

Le problème avec cette occupation optimisée de la capacité de travail, c’est que la roadmap ressemble désormais à ça:

On peut faire pire. Il y a une variante de la roadmap de projets appelée “roadmap matricielle”. En  voici une vue d’artiste (vous remarquerez les “jolies couleurs”, partie intégrante du concept).

La roadmap matricielle présente une certaine élégance et peut donner l’apparence d’une maîtrise plus pointue du sujet. Après tout, il faut être plus intelligent pour appréhender les choses en deux dimensions qu’en une seule, non ? Cela bien établi, on se demande pourquoi personne n’a encore eu l’idée de réaliser des roadmaps tridimensionnelles ! La difficulté de rendre cela sous Powerpoint, j’imagine …

En réalité la roadmap matricielle amplifie les travers de la roadmap de projets :

• Plus d’embouteillage : ce n’est plus une file de projets qui en en attente mais une série de files d’attentes ! L’image du péage de Saint Arnoult s’impose à moi !
• Alignement des ressources avec le plan. Il est bien facile d’ajouter une ligne à une matrice. Mais qu’en est-il des équipes de développement ? La pratique montre qu’elles sont rarement dimensionnées en conséquence. Souvent cela se traduit par du temps partagé de développeurs (un désastre) ou des équipes de développement fractionnées pour atteindre des tailles d’une ou deux personnes pour certaines d’entre-elles…
• Pas de focus stratégique. On attend d’un comité de direction qu’il donne justement une direction ! Que peut-il faire quand il est incapable de mener à bien sa mission première ? Il peut ne pas décider de direction stratégique et clamer que “toutes les directions sont prioritaires”. La roadmap matricielle traduit cela.

Qu’elle soit matricielle ou non, la roadmap a des conséquences dont nous allons nous rendre compte qu’elles sont des effets de bord de son existence même. Ce sont pour la plupart en fait des effets psychologiques.

Conséquences, conséquences

La persistance dans l’action

L’une des vertus de la roadmap est de montrer que derrière le projet en cours, il y a un ou plusieurs projets en attente. En principe c’est un bienfait, ce n’est même pas complètement négatif, même si je vais prétendre l’inverse dans deux secondes.

Mais concentrons-nous sur notre projet en cours.

Etant agile, vous savez que l’intérêt d’un projet ainsi réalisé réside dans le feedback, l’émergence de nouvelles idées porteuses de valeur ou l’abandon d’idées initiales qui finalement n’en ont pas. Dit autrement, on devrait arrêter un projet quand il n’y a plus de valeur business dans les fonctionnalités à venir, par contre on devrait le poursuivre si la valeur de ces fonctionnalités à venir le justifie. Il n’est d’ailleurs pas rare que les fonctionnalités différentiantes arrivent relativement tardivement car on doit au préalable assurer les fonctionnalités de base, comme le montre le modèle de Kano.

Hélas la file d’attente crée une pression psychologique vers l’arrêt du projet, même si les fonctionnalités à venir sont intrinsèquement porteuses de valeur. Il faut certes juger de l’intérêt de poursuivre ou passer à autre chose, mais la roadmap tend à créer un biais dans la décision dans le sens de la tenue du plan.

La rigidification du changement

Une roadmap de projet, c’est un plan. Et créer un plan, ça prend du temps. Combien de temps (en délai) allez-vous prendre pour prioriser avec un comité de direction un portefeuille de 20 ou 30 projets ? Si votre réponse est “1 mois”, je pense que vous vous en tirez bien. Généralement, ce sera plutôt plus.

Maintenant, partons sur l’hypothèse de 2 équipes traitant des projets allant de 6 mois à 1 an, ce qui est compatible avec une roadmap d’une vingtaine de projets soit disons 3 ans de travail. Statistiquement, on va donc se retrouver avec un démarrage de projet tous les 3 à 6 mois. Quelle est la probabilité pour qu’un comité de direction réévalue cette roadmap à chaque début de projet (tous les 3 à 6 mois), avec un délai de réévaluation qui sera de 1 à 2 mois ? En théorie, c’est faisable, dans la pratique c’est au mieux improbable.

On se retrouve ainsi devant l’alternative suivante:

• Pas de réévaluation du portefeuille et on suit le plan sans le remettre en cause, en tout cas pas à chaque début de projet.
• Le bon sens prédomine, et lors du début du projet suivant, on démarre le projet qui parait être le plus important pour la société, qui n’est pas nécessairement celui prévu par la roadmap. Et la roadmap devient gentiment obsolète…

Incapacité à faire face à l’imprévu

L’un des autres effets pervers de la roadmap est l’effet d’encombrement qu’elle donne. En rendant visible (et priorisés) un grand nombre de projets, elle provoque une censure, voir une autocensure par rapport à de nouvelles opportunités business qui demandent un changement radical de direction. La présence même de la roadmap crée un frein psychologique à l’idée d’arrêter là un développement en cours ou de le réorienter.

Une variantes de ceci est la perte d’opportunités pour les équipes de réalisation elles-mêmes : crucifiées à leur roadmap, elles voient les projets d’actualité passer en d’autres mains car “ces pauvres gars sont bien trop occupés, il faut les soulager”. Là encore l’effet d’encombrement se substitue à l’importance business des projets qui émergent.

Quand c’est pas cher, c’est prioritaire

L’analyse et la priorisation d’un portefeuille de projets se font souvent sur la base d’indicateurs associés à ces projets : risque, importance business, coût, etc… En soi cela est une bonne chose même si calibrer l’importance relative de ces indicateurs est à la fois subjectif et délicat. Mais hélas ce processus nous expose lui-même à deux travers:

• Perdre de vue l’axe stratégique que l’on s’est fixé.
• Tomber dans le syndrome de la priorisation par le coût : “ce projet est tout petit, on doit pouvoir le caser avant ce gros”. Une fois tombé dans cette logique, le corollaire est une importance exagérée donnée à la quotation des projets (elle conditionne majoritairement les priorités), donc une logique de coûts préétablis sur les projets fonction des spécifications et par là même une sclérose anticipée du périmètre fonctionnel !

La roadmap de projets, c’est du stock

Quel est l’intérêt avéré d’analyser, évaluer et prioriser une vingtaine de projets lorsqu’au final c’est un et un seul projet qui démarrera au prochain démarrage de projet ?

En fait, il y a bien un intérêt : s’assurer que le bon projet à démarrer est bien celui que l’on a choisi et aucun des 19 autres ! Mais quel est l’intérêt de déterminer que les projets en position 4 et 5 sont correctement priorisés ? Ou même que celui mis en seconde position est le bon ? Le Lean nous apprend deux choses importantes:

• Le stock, c’est du gâchis. Il doit être éliminé.
• Les décisions doivent être différées jusqu’au “dernier moment responsable”. Ce dernier moment responsable, c’est celui où l’on va effectivement démarrer le projet.

Etablir, entretenir, réévaluer de longues listes de projet, c’est indubitablement du stock. Combien de projets de cette liste ne seront même jamais démarrés?

Et la roadmap agile ?

Depuis quelques années est apparu le concept de “roadmap agile”. La littérature sur le sujet n’est pas très abondante non plus, mais elle existe. Vous trouverez d’ailleurs une note de lecture sur un de ces ouvrages sur ce blog.

Quel est le but d’une roadmap agile ? Il reste de gérer et prioriser un portefeuille de projet, mais de manière plus efficace en ne remontant que les informations pertinentes à la priorisation. Donc, on décide plus efficacement sans s’engluer dans une masse d’information et un niveau de détails qui ne sont pas pertinents à ce niveau. On est aussi plus efficace à collecter et analyser l’information en amont. Bref, on se met en condition pour permettre le suivi et l’évolution itérative du portefeuille.

Mais cela reste quand même du stock !

Quelle alternative(s) ?

Analyser un gros portefeuille de projet est-il nécessaire ?

D’un point de vue des équipes de réalisation on a guerre besoin d’avoir une vingtaine de projets priorisés. On a même pas besoin d’avoir une visibilité sur ces vingt projets. On a juste besoin de connaitre le prochain projet. Avoir une idée des un ou deux suivants tels qu’on les imaginent aujourd’hui peut aider à donner de la perspective, pour autant que l’on accepte que la vérité d’aujourd’hui ne sera peut-être pas celle de demain…

D’un point de vue business, c’est un peu différent. Il faut identifier le (ou les quelques) bon(s) projet(s) à réaliser. Mais il n’est pas utile de recenser et surtout analyser tous les projets potentiels de l’entreprise ou du département pour cela. Si la stratégie est clairement identifiée, les quelques projets les plus importants remonteront naturellement. Et il y a de bonnes chances pour que ce soit les bons.

Le problème est la “stratégie clairement identifiée”. Ce n’est pas un boulot si facile que cela, mais c’est celui que l’on attend d’une direction.

Se livrer à une grande foire des projets, pardon à une roadmap des projets est aussi une façon d’abdiquer à l’établissement de cette stratégie.

Alors la roadmap, c’est mal ?

C’est le moment où je ne vais pas répondre à la question. C’est à vous d’y répondre.

La roadmap n’est pas intrinsèquement mauvaise, surtout si on essaie de la mener en agile. La vertu qu’elle doit porter est de donner de la perspective.

On peut aussi avoir une liste des “projets potentiels”, sorte d’aide-mémoire entretenu au fil du temps et de discussions informelles. Je le fais. Et cela m’aide lorsque le sujet et des sujets proches sont évoqués.

Mais les effets néfastes de la roadmap de projets existent et peuvent être plus importants que ses bienfaits. A vous de juger.

Personnellement je pense que la roadmap commence par une stratégie. Elle doit permettre de se focaliser sur un petit nombre de projets.