Le dessous des cartes agiles de la transformation numérique de France Télévisions Editions Numeriques

Voici la présentation que j’ai eu le plaisir de partager lors du ScrumDay 2014.

Comment introduire l’Agile ? Pourquoi passer du projet au produit ? Comment bien démarrer un projet ? Quelles exigences vis-à-vis de la qualité ? Comment gérer l’urgence et l’importance ? Comment partager l’information efficacement ? Comment protéger l’équipe et garder l’esprit agile ? Autant de questions que je me suis posées lorsque je suis arrivé dans mon nouveau poste à la direction technique de FTV Éditions Numeriques. Au travers de 7 « cartes Agiles », je reviendrai sur les différentes étapes de cette transformation, ce qui a marché (#success), ou pas (#fail) …

Précaution : cette présentation n’a pas pour vocation à présenter des modèles « théoriques » mais bien mon retour d’expérience d’une transformation agile dans le contexte particulier et singulier du Numériques chez FTV. Le but est de présenter ce qui a été fait chez FTVEN depuis 2 ans. c’est ce que j’appelle la transformation Agile dans un contexte Numériques, avec des équipes produits.

Lien vers le film (slide10) : https://www.youtube.com/watch?v=rE6D6GIiyPU

Publicités

Atelier Vision et Enjeux

L’objectif est de définir la vision et de questionner la stratégie, la raison d’être du projet et les mesures du succès.

Préambule : cet article s’inscrit dans la suite de celui sur le cadrage. Je vais décrire ce qui me parait important dans cet atelier et les « outils » que j’ai déjà utilisés. Par contre, je ne vais pas décrire comment animer cet atelier. Pour cela, je vous laisse le soin de contacter Jean-Claude Grosjean (@jcQualitystreet) et Guillaume Duquesnay (@duquesnay) pour plus de détails sur les techniques de facilitation.


 Faire émerger la vision 

VisionCommençons par la vision, puisque un des buts de cet atelier est justement de faire partager la vision du produit ou du projet que vous souhaitez réaliser. Ah? Produit ou Projet?

Vision Produit vs Vision Projet

Alors, Produit ou Projet? Ma définition est finalement assez simple : un projet est un ensemble d’activités qui permettent d’aboutir à un livrable. Ce livrable peut donc être soit un produit dans sa globalité, soit, plus vraisemblablement, une version (release) de ce produit. Le produit va donc avoir une temporalité plus large que celle du projet. Alors, pourquoi parler de projet? Personnellement, je préférai parler de version du produit. Cependant, dans les grandes entreprises, il est plus commun de parler de projets, d’autant que les budgets sont souvent articulés autour de cette notion. Le soucis que j’observe fréquemment est que ces budgets concernent quasi-exclusivement la première version d’un projet; du coup, cela peut donner lieu à une vision court-termiste, et donner l’impression qu’une fois le projet terminé, le produit sera aussi terminé. Or, c’est rarement le cas… Dans cet atelier, je vous conseille de présenter les deux aspects :

  • la vision du produit : l’ambition que vous vous donnez, là où vous voulez aller, ce que ce produit va (possiblement) apporter. Par exemple, « Nous souhaitons ouvrir une plateforme de contenus culturels en présentant des vidéos de spectacles vivants, en direct et en différé. Cette plateforme sera distribuée sur tous les écrans, web, smartphones, tablettes, TVC, box FAI et box OTT ».
  • la vision du projet : pour faire simple, il suffit de positionner le projet dans la vision du produit. Par exemple, « Dans le cadre de ce projet, nous allons d’abord proposer cette plateforme de contenus culturels sur le web, les tablettes et sur un seul constructeur TVC (pas sur les autres écrans) ».

Vision Produit

Puisque la vision du produit enveloppe la vision du projet, nous allons nous focaliser sur les moyens de faire émerger celle-ci. Tous les contextes sont évidemment différents. Si la vision du produit a déjà été définie par ailleurs, il suffit de la partager et de s’assurer qu’elle est claire pour tous. Par contre, si elle n’a pas encore été définie, il convient de se lancer dans un phase d’ouverture, où vous allez « ouvrir vos chacras » et accepter les idées de tous les participants à l’atelier. Le choix de ces derniers devient donc primordial. Attention: dans ce cas, un seul atelier Vision & Enjeux ne sera probablement pas suffisant et vous devrez le renouveler jusqu’à obtenir une vision du produit claire.

Des jeux pour doper l’imagination 

Il existe de nombreux « outils » pour aider à faire émerger la vision du Produit, qui sont d’ailleurs regroupés sous le vocable anglais de « Innovation games ». La plupart de ceux que j’ai utilisés proviennent de Luke Hohmann et de son livre « Innovation Games: Creating Breakthrough Products Through Collaborative Play » (cf référence à la fin de l’article). Cela peut faire un peu peur de se lancer dans ce type de « jeux », mais je vous encourage à être courageux, à sortir de votre zone de confort et de jouer justement le jeu car les résultats sont toujours au rendez-vous. Quelques exemples intéressants:

  • Product box : permet d’identifier les caractéristiques les plus excitantes d’un produit. Demandez à l’équipe de concevoir un boite qui va représenter votre produit comme s’il devait être vendu et apparaitre sur les rayonnages d’un magasin. Ils vont pouvoir habiller la boite avec des slogans, des coupures de magazines, des prix… Une fois réalisée, demandez à un membre de l’équipe de la présenter, de la vendre.
  • Speed boat : permet d’identifier ce que les utilisateurs n’aiment pas dans votre produit. Vous dessinez un bateau, un bateau que vous souhaitez voir avancer tres rapidement. Malheureusement, celui-ci est retenu par des ancres qui le ralentissent… Evidemment, le bateau représente votre produit et les ancres les fonctionnalités que vos utilisateurs n’aiment pas. Les ancres sont placées plus ou moins bas dans la mer, et au plus c’est bas au plus c’est un frein pour le produit. Ce qui est intéressant c’est la discussion qui s’installe entre les participants à cet exercice pour déterminer le niveau où on va situer l’ancre. Cet exercice est aussi utile pour discuter d’une organisation.
  • Remember the future : là, c’est très simple, il suffit de s’imaginer ce qu’il s’est passé dans le futur si tout c’est bien passé et que le produit a été un succès. Cela permet d’identifier les critères de succès, souvent vus des clients, des utilisateurs finaux.

La vision en une phrase

Pour terminer, essayez de résumer la vision du produit en une phrase. Cela ressemble un peu au concept des 30 secondes pour convaincre le PDG dans l’ascenseur, le fameux « Elevator Pitch ». C’est un exercice assez difficile à réaliser, mais il me semble important car les acteurs du projet vont pouvoir se l’approprier et j’ai souvent observé qu’ils réutilisaient cette phrase quasiment mot pour mot pour expliquer le produit à des collègues.


Le sponsor, pas toujours le génie que l’on croit…

Pour réaliser ce travail sur la vision du produit, il est donc primordial de bénéficier de la présence active du sponsor puisqu’il va pouvoir exprimer ses souhaits, l’ambition du produit, les grandes orientations… A ce stade, je voudrais démystifier un petit peu ce sponsor, que l’on prend parfois pour un génie. Bien sur, on a tous en tête les Steve Jobs, Bill Gates, et autres Zuckerberg ou Dorsey… Mais, car il y a un mais, dans les grandes entreprises, le sponsor est rarement un génie, qui a la vision infuse… Désolé, mais cela arrive rarement. D’ailleurs, une raison valable et validante est que si c’était le cas, il irait surement créer sa propre boite 😉

Donc, dans les grandes entreprises, il est fréquent que le sponsor possède un des profils suivants :

  • le sponsor « idéal » : rare mais cela existe quand même. Il est capable de définir la vision, les enjeux, le périmètre du produit de manière claire et synthétique. Et en plus, il est disponible. Si cela vous arrive, vous pouvez considérer que vous avez gagné au loto! Bon, honnêtement, je n’ai rencontré ce type de sponsor que dans des contextes de startups, la startup du sponsor. CQFD.
  • le sponsor « exécutif » : il sait définir la vision mais il n’a pas le temps… Du coup, tout au long du cadrage (puis du projet), on va se demander « comment IL aurait fait, ce qu’IL a en tête… » Invariablement, ce que l’on aura prévu ne LUI conviendra pas, et il faudra défaire et refaire… Plusieurs fois… Frustrant et démotivant pour les équipes… Mais, avec le temps, on y arrive quand même et c’est déjà très bien.
  • le sponsor « impliqué » : celui qui est finalement le relais du sponsor « exécutif ». Si tout se passe bien, il va tout de même pouvoir prendre des positions et des décisions dans bon nombre de situations. Sa relation avec le sponsor « exécutif » est primordiale. Surtout, il va s’appuyer sur tous les acteurs du projet, ce qui au final peut donner lieu à un vrai travail d’équipe.
  • le sponsor « quicroitquilsaittout » : ca, c’est le cas le plus pénible… Il a les barrettes, le mandat mais n’a pas la vision… Surtout, il n’aura pas de relation de confiance avec le sponsor « exécutif » et il ne va pas s’appuyer sur l’équipe parce qu’il pense détenir LA responsabilité et LE pouvoir de tout décider. L’équipe va passer de l’enthousiasme à la déception très rapidement. Il est fort possible que le projet tombe a l’eau…
  • le sponsor « sans pouvoir » :  on lui a dit qu’il était sponsor mais en vrai, il ne possède pas soit la pertinence soit la confiance requise du top management. Du coup, l’équipe va rapidement se résigner voire se désengager… N’hésitez pas, ne perdez pas de temps, quittez vous aussi le navire!

Evidemment, je caricature un peu, même si ce que je décris est quand même du vécu!


 Identifier les enjeux

Une fois la vision définie et clarifiée, il est intéressant de formaliser les enjeux. Les enjeux peuvent se révéler être de différentes natures (pour n’en citer que quelques uns, les plus classiques):

  • Stratégiques : chiffre d’affaires, reach, performance opérationnelle, ROI, position sur le marché…
  • Usages : accès à l’information, expérience utilisateur, multi-distribution…
  • Contenus : nouveauté du contenu, enrichissement, recommandation, croisement ou agrégation d’informations…
  • Techniques : innovations ou évolutions technologiques…
  • Internes à l’entreprise : amélioration de processus, de la qualité, de la productivité, économies…
  • Internes à l’équipe projet : capitalisation sur une connaissance, une méthodologie, une technologie…

Idéalement, vous serez en mesure de qualifier clairement l’atteinte d’un enjeu, même si ce n’est pas toujours possible ou facile lorsque certains de ces enjeux sont « quali », plutôt que « quanti ». Finalement, le plus simple est de se poser la question « cet enjeu sera atteint si… »  Si possible, je vous encourage à prioriser les enjeux, les uns par rapport aux autres. Si cela s’avère trop difficile de dire que « cet enjeu est plus important que celui-là, parce qu’ils s’ont complémentaires », établissez 3 catégories :

  • Enjeux d’ordre 1 : si on ne les atteint pas, le projet sera un échec. Si on les atteint, on a fait le taf, c’est super.
  • Enjeux d’ordre 2 : si on les atteint, c’est excellent (si les enjeux d’ordre 1 ont aussi été atteints).
  • Enjeux d’ordre 3 : si on les atteint, c’est la cerise sur le gateau, c’est vraiment exceptionnel (si les enjeux d’ordre 1 et 2 ont aussi été atteints).

N’hésitez pas à partager ces enjeux et à les faire challenger pendant toute la phase de cadrage, mais aussi tout au long du projet. Adaptez-les si nécessaire en toute humilité.


Définir le périmètre du projet 

Une fois la vision et les enjeux du produit définis et clarifiés, vous allez pouvoir en tirer et préciser le périmètre global du projet.

L’ouverture, c’est bien, mais restons réalistes!

L’objectif est d’aboutir à une vision partagée à la fois du produit mais surtout du projet que l’on va réaliser. Il faut donc arriver à en définir les frontières et les contraintes peuvent y aider! Les évènements vont vous imposer une date qui ne sera pas négociable en avance (ex: les JO ou les élections). Le budget ou l’espace physique dont vous disposez pourront aussi contraindre la forme de votre projet. Il va donc falloir possiblement sélectionner certaines fonctionnalités, réduire l’ambition… No stress et rappelez-vous d’André Gide: choisir c’est renoncer.

Agile et projet, est-ce compatible?

Depuis quelques années, les méthodes Agiles se sont petit à petit imposées permettant de produire des produits émergents avec des équipes agiles qui ne cessent de mettre en production de nouvelles fonctionnalités, au fil de l’eau… Pourquoi parler de projet dans ce cas? De mon expérience, et bien sur je parle plutôt des contextes d’entreprises ou d’éditeurs de logiciels, plutôt que celui de startups (encore que), il est intéressant de se fixer les limites d’un « projet » afin d’éviter le syndrome de la longue litanies des sprints interminables où l’équipe ne voit plus ce qu’elle a construit. Je caricature. Et d’ailleurs, ce n’est pas parce que l’on travaille en Agile qu’on ne peut pas se fixer des « projets » pour construire un produit. Je le répète, je préfère parler de version alignée sur des fonctionnalités (releases & features) dans le cas d’un produit qui ne va cesser d’évoluer dans le temps. Donc, pour réaliser un produit complexe, je vais définir un projet, composé de plusieurs chantiers. Ces chantiers peuvent être réalisés en agile, de manière itérative.

Il n’est pas nécessaire d’être précis

Je l’ai déjà dit et je le répète : il n’est pas nécessaire de se contraindre à tout définir, bien au contraire. Grâce aux méthodes agiles (mais surtout au bon sens de gens intelligents), il sera possible d’ajuster le périmètre, en fonction de l’apprentissage sur les premiers sprints, et tout au long de la réalisation. A ce stade, il suffit d’identifier les fonctionnalités, « grosses mailles », qui semblent nécessaires au développement du produit. Les méthodes agiles conseillent de commencer par développer les fonctionnalités du produit les plus importantes. Comment identifier ces fonctionnalités et donc le périmètre de ce projet? C’est d’abord la vision du projet et le sponsor qui vont vous le permettre. Puis les contraintes. Il se peut que vous identifiez des fonctionnalités qui ne seront pas utilisées… Depuis quelques années, le Lean startup propose d’aller chercher des preuves de l’intérêt de votre audience pour ce que vous imaginez comme étant un produit intéressant. C’est le fameux MVP, Minimum Viable Product. Le MVP est particulièrement adapté dans le cadre particulier d’une startup, qui possède beaucoup d’agilité et doit aller chercher du reach, de l’audience, des moyens pour survivre. Dans le contexte de grandes entreprises, ce MVP est tout aussi souhaitable pour éviter de réaliser des projets trop longs, des fonctionnalités qui ne servent à rien, des produits qui ne trouvent pas leur public… Cependant, le MVP ne sera pas exactement le même que pour une startup. Par exemple, si je dois réaliser la plateforme pour couvrir les Jeux Olympiques pour France Télévisions, il est inconcevable que je ne conçoive pas un système à la fois complet et robuste. Je sais déjà par avance qu’il y aura un succès d’audience suffisant pour avoir des problèmes 😉 Par contre, toujours dans le cadre de France Télévisions, si nous lançons un projet d’innovation en mode Test & learn, alors, évidemment, on sera dans un projet où on aura un MVP beaucoup plus restreint.  Bref, adaptez le MVP à votre contexte!

Et d’autres jeux pour définir le périmètre

De la même manière qu’il existe des « Innovation games » pour clarifier la vision du produit, il existe des jeux pour aider à prioriser les fonctions, ou tout du moins à définir un périmètre au projet:

  • Buy a feature : le but est de prioriser les fonctionnalités en demandant aux acteurs de les acheter. Une variante qui a ma préférence est de donner des gommettes (3 ou 5) à tout le monde et de demander de les placer sur les fonctionnalités qui ont leurs préférences. Ils ont le droit de poser plusieurs gommettes sur la même fonctionnalité.
  • Prune the product tree: le principe est de définir un arbre dans lequel le tronc correspond au produit, les branches au fonctionnalités actuelles et les feuilles aux nouvelles fonctionnalités. L’objectif est de « tailler » le produit en fonction des besoins. Personnellement, je préfère un exercice de priorisations des fonctionnalités.
  • IN/OUT : une autre manière de déterminer le périmètre du projet est d’exprimer ce qui ni est pas : on peut donc construire la liste des fonctionnalités qui sont inclus dans le projet, et une autre liste des fonctionnalités qui n’y sont pas. Cet exercice est très efficace.

Un mot sur l’impact Mapping

Plusieurs personnes m’ont parlé de l’Impact mapping lors de mon article précédent. J’avoue que je n’ai pas d’expérience suffisante pour pouvoir donner un avis pertinent. Pour ceux que cela intéresse, n’hésitez à regarder le site dédié  et la présentation suivante. L’impact mapping propose de regarder le problème en adressant les questions « Pourquoi? -> Qui? -> Comment? -> Quoi? ». Vous l’avez compris, le principe du cadrage tel que je vous le propose adresse évidemment ces mêmes questions au travers de plusieurs thématiques. Il me semble même que cela va un peu plus loin puisqu’on répond à des questions plus précises d’architecture, de financement, de localisation, de méthode… En fait, personnellement, j’utilise un moyen complémentaire qui s’appelle le CQQCOQP : c’est Dan Roam qui, en plus de proposer de décrire le problème avec des schémas simples (ceux qui me côtoient savent à quel point je raffole de schémas simples sur mon grand tableau blanc), propose aussi cet acronyme CQQCOQP qui correspond aux questions Comment, Quoi/Qui, Combien, Où, Quand et Pourquoi. Utilisez-le pour vous assurer qu’un sujet a été bien couvert.


Quelques références de livres ou ressources qui m’ont influencé sur ce thème :

Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann

Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann

The Back of the Napkin: Solving Problems and Selling Ideas with Pictures by Dan Roam

The Back of the Napkin: Solving Problems and Selling Ideas with Pictures by Dan Roam

Manage It! - Johanna Rothman

Manage It! – Johanna Rothman

De l’importance du cadrage de projet

Préambule
Cet article est une dédicace à Esther Derby (http://www.estherderby.com/) qui m’a réellement influencé lors de son intervention à l’USI 2012 où elle y a présenté le concept de «60/30/10».

Je vous encourage à revivre cette présentation grâce à nos amis de @USIEvents qui ont re-publié cette vidéo en un temps record! 


Et n’hésitez pas à visiter le site Youtube de l’USI pour encore plus de vidéos.

Le principe de 60/30/10

Lors de sa présentation, Esther se basait sur une étude menée par J. Richard Hackman (cf lien en fin d’article) dans laquelle il démontre au travers de ses nombreuses recherches que l’efficacité d’une équipe est directement liée à la manière dont elle est construite et lancée :

  • 60% de l’efficacité d’une équipe se décide à la construction de l’équipe (avant son lancement)
  • 30% au lancement
  • 10% dans la suite du projet (après le lancement)

Par extension et projection sur la réalisation de projets informatiques, Esther en déduisait que beaucoup de choses se passent donc avant et pendant le kick off d’un projet, et qu’il faut par conséquent apporter une attention particulière à la manière dont on construit l’équipe.

J’en ai retiré 3 points importants :

  • le cadrage
  • la construction de l’équipe
  • le lancement (ou kick off)

Afin que cet article ne soit pas trop long, je vais surtout parler du cadrage. Je reviendrai dans un autre article sur les 2 autres points.

De l’importance du cadrage

Combien de fois ai-je fait le constat qu’un projet était parti trop vite, sans réel partage d’une vision claire, des enjeux, des échéances clés, de l’attente des sponsors, voire des moyens alloués, de l’architecture globale ou encore de l’organisation? Un nombre bien trop important, j’en ai peur… Fort de ce constat et de la mise en perspective d’Esther, nous avons formalisé, au sein de ma direction, ce qui se passe en amont d’un projet sous la forme d’un cadrage, dont l’objectif principal est de lancer le projet sur de bons rails et de le sécuriser.

Qu’est-ce qu’un cadrage?

« Une préparation réalisée en temps contraint, au cours de laquelle se succèdent un certain nombre d’activités et d’ateliers permettant d’aligner tout le monde autour de thématiques structurantes, qui se termine par un livrable global et synthétique pour validation et démarrage effectif du projet  »

Allez, déconstruisons cette définition!

Réalisé en temps contraint

Il est important de bien cadrer mais il est tout aussi important de réellement démarrer le projet! Un cadrage trop long, avec trop de temps passé à définir et décrire le projet, peut être tout à fait contre-productif. Il faut donc trouver le bon compromis. L’idée ici est de se contraindre par le temps et de se dire que ce n’est probablement pas grave si on n’a pas eu le temps de TOUT cadrer. Cela permet surtout de se concentrer sur l’essentiel.
Alors, combien de temps allez vous me demander pour un bon cadrage? Et bien, cela dépend beaucoup du contexte, de la complexité du projet, de l’âge du capitaine et tout et tout. Bon, de mon expérience, je pense qu’il est possible de cadrer la plupart des projets entre 4 à 6 semaines. Finalement, ce qui contraint le plus un cadrage est souvent la disponibilité des sachants et des sponsors!

Des ateliers pour détailler les thématiques structurantes

Comme le montre le schéma suivant, le cadrage comporte 6 ateliers permettant de dégager les éléments les plus structurants des thématiques suivantes :

Cadrage de projets

De façon à obtenir une meilleure efficacité, je vous recommande de contraindre dans le temps chaque atelier, de vous assurer de la disponibilité des bonnes personnes (notamment le sponsor) et de faire valider les résultats de chaque atelier au plus tôt. Les ateliers peuvent durer 2 à 4 heures. De mon expérience, il est quasiment impossible de mener les ateliers en parallèle puisqu’ils impliquent souvent les mêmes acteurs. Je vous conseille donc de les réaliser dans l’ordre présenté ci-dessus. Par contre, il n’est pas impossible que le résultat de certains ateliers viennent influencer ce qui a été défini dans un atelier précédent. C’est même une évidence et il faudra souvent plusieurs aller-retours avant d’obtenir une version aboutie. C’est normal et logique. Par ailleurs, certaines thématiques peuvent nécessiter plusieurs ateliers, ou même une préparation adaptée. Par exemple, l’architecture d’une nouvelle application peut donner lieu à plusieurs ateliers, voire à la réalisation de preuves de concept (POC) permettant de valider la faisabilité de certaines hypothèses techniques.
Afin de conserver cet article lisible (not tl;tr), je décrirai ces différents ateliers dans un prochain article.

Aligner tout le monde

Le cadrage, au travers des ateliers, va permettre d’aligner un nombre important d’acteurs clés du projet sur un même objectif. Cela concerne souvent 4 populations différentes, qui peuvent être mélangées en fonction de votre organisation :

  • le fonctionnel (aussi appelé Métier ou MOA)
  • le marketing
  • la technique (aussi appelé MOE)
  • l’exploitation (aussi appelé Production ou Opération)

Au-delà de ces acteurs opérationnels, il faut aussi s’assurer que les « décideurs » seront impliqués et informés des orientations choisies. Je peux vous assurer que cette tâche n’est pas la plus simple!

Un livrable global et synthétique

Le livrable est dit « global » puisqu’il va contenir l’ensemble des éléments structurants dans un seul et même document. Malgré cela, le document doit être le plus clair et synthétique possible. Je vous encourage à utiliser beaucoup de schémas qui, selon l’adage bien connu, valent mieux que de longs discours! A partir de cette présentation, vous allez pouvoir réaliser un poster synthétique du projet que vous collerez au mur, et tout autre présentation que vous aurez à faire en l’ajustant en fonction de votre public.

Validation

Il est fondamental que le cadrage soit validé par les décideurs de votre organisation. De mon expérience, les points les plus critiques et qui nécessitent une attention particulière, sont :

  • l’organisation : assurez vous que les acteurs positionnés sur les rôles de sponsor, Product Owner, possèdent à la fois la pertinence et les mandats nécessaires.
  • les ressources ou le budget : assurez vous que le budget alloué est légitime et pertinent. Attention aux projets qui souhaitent partir coute que coute, avec un budget ou un planning sous-taillé… Vous en payerez toujours les conséquences. (cf l’article sur la planification réaliste).
  • l’architecture : assurez vous que l’architecture proposée respecte les standards de votre entreprise ou au moins que vous assumez en connaissance de cause que cela ne soit pas le cas.

Démarrage effectif du projet

Du livrable, vous allez pouvoir en tirer une présentation de communication pour le kick off. Ce kick off est donc le prochain moment clé qui va permettre à toute l’équipe de se mettre en mouvement et démarrer le projet. Mais ça, c’est une autre histoire 😉

Pour en terminer sur le cadrage, j’ai toujours en tête une phrase qui m’aide à obtenir le bon état d’esprit:

L’important n’est pas tant le résultat que le chemin que nous parcourons ensemble!

PS: je tiens à remercier Jean-Claude Grosjean (@jcQualitystreet) et Guillaume Duquesnay (@duquesnay) avec qui j’ai la chance de collaborer au quotidien et qui ont largement participé à ce travail de formalisation.

Quelques références de livres ou ressources qui m’ont influencé sur ce thème :

Collaborative Intelligence: Using Teams to Solve Hard Problems - J. Richard Hackman

Collaborative Intelligence: Using Teams to Solve Hard Problems – J. Richard Hackman

Manage It! - Johanna Rothman

Manage It! – Johanna Rothman

Monsieur le DSI, vous voulez des plannings réalistes?

Dans mes expériences passées et dans mon rôle actuel, j’ai vu passer de nombreux projets informatiques. Et bien sur, j’ai été témoin d’un nombre non négligeables de dysfonctionnements… Avant de vous ennuyer avec des considérations pragmatiques et pourtant un peu « théoriques », je vais commencer par une anecdote personnelle.

Monsieur le DSI, vous voulez des plannings réalistes?

Elle date du temps où j’oeuvrais en tant que consultant pour le compte d’une société d’assurances. Le DSI (un homme que je respecte au plus haut point) m’avait demandé de l’aider à monter une cellule d’analyse des risques. « Tu comprends, Alain, le portefeuille de projets est tellement grand que j’ai besoin d’aide pour identifier les risques importants dans les projets. J’en ai marre des projets qui passent du jour au lendemain du VERT au ROUGE sans que l’on n’ait rien vu venir… Tu peux aller voir n’importe quel projet, rentrer dans n’importe quel comité de pilotage. Tu dis juste que tu viens de ma part. » J’ai été poli, je me suis toujours annoncé.
Un jour, je vais voir un chef de projet et je lui demande de me montrer le planning de son projet. Le planning allait en se réduisant avec beaucoup de temps pour les spécifications, la conception puis moins de temps pour les développements et vraiment plus grand chose pour les tests de recette. Oui, la méthode était bien une cascade et là, ça chutait sec!
Moi: « Ne penses-tu pas que ton planning n’est pas réaliste? »
Lui : « Ben, si, je sais bien… On finit toujours les développements sur les phases de recette et on déborde sur le prochain lot du projet… C’est comme ça… »
Moi: « Mais, puisque tu le sais, pourquoi tu ne fais pas directement un plan réaliste? »
Lui : « Ben, c’est que les Managers veulent voir ces dates là! »
Moi : « Tu leur as vraiment demandé aux managers? Tu leur as dit que le planning n’était pas réaliste? »
Lui : « Non, c’est pas la peine, toute l’équipe le sait déjà. Et puis, on a fait un chiffrage initial et franchement, ce n’est pas facile, j’ai du mal à être précis… Bref, je ne sais pas justifier que ce n’est pas réaliste tant qu’on n’a pas tenté… Mais, bon, je suis d’accord, là on sait déjà qu’on ne va pas y arriver… »
Moi : «  Bon, je te propose que tu gardes ce planning pour le moment, mais prépare moi aussi un planning qui te semble le plus réaliste possible, en prenant en plus un peu de marge en cas d’imprévu. Moi, je m’occupe du reste. »
Lui: «  Eh! Déconne pas, je vais perdre mon job moi!! »
Moi : « T’inquiète… »
Je le laisse et je vais voir le DSI. Je toque à la porte. « ENTREZ! » Je rentre et lui demande: « Est ce que tu veux des plannings réalistes ou pas sur tes projets? »
Evidemment, vous devinez facilement sa réponse. Le plus rigolo est qu’une fois que nous avons mis au point un planning « réaliste », nous sommes allés le présenter aux autres projets connexes. Tous ont eu la même réaction : « Ah, mais si on peut maintenant le dire, nous aussi notre planning n’est pas réaliste!!! »

Donne un chiffre (ou une date) et il sera gravé dans le marbre!

Cette anecdote amusante, et pourtant tout à fait réelle, illustre bien 2 phénomènes : 1/ il est difficile d’estimer et 2/ il arrive fréquemment que les chefs de projet planifient ou chiffrent en fonction de ce qu’ils pensent que les managers attendent d’eux… Le plus dramatique est que ce jeu de dupes s’installe facilement par un phénomène assez connu : celui de l’annonce initiale. Enoncez un chiffre, une date, et celui-ci sera pris comme s’il avait été gravé dans le marbre! Ce phénomène est d’ailleurs bien connu puisqu’un bon négociateur n’énoncera jamais le premier chiffre et attendra que l’autre commence en premier. Cependant, nous ne sommes pas en train d’acheter une voiture ou une poterie au souk de Marrakech mais bien de faire une première estimation d’un projet informatique. Et il existe tellement de facteurs qui peuvent impacter grandement sa réalisation (la compréhension du besoin, la complexité du projet, la vélocité de l’équipe, les imprévus, les changements…) qu’il est finalement logique de ne pas pouvoir être précis. Mais, donne un chiffre et il restera…

Le biais du chiffrage budgétaire

Dans les grandes entreprises, arrive à un moment ou à un autre, le moment où « il faut faire les budgets pour l’année prochaine». A cela, rien d’illogique bien sur, surtout que l’objectif n’est pas d’être précis mais de fonctionner avec des grosses masses et de prévoir le budget nécessaire pour accomplir les projets alignés sur les grandes orientations stratégiques. On découpe donc ce budget en projets d’investissements, et on essaie de qualifier, « à la grosse louche » ou «  au pif », ces projets. La question n’est d’ailleurs pas tant de savoir combien coute tel ou tel projet mais plutôt d’évaluer combien on est prêt à investir. Et surtout, on se donne une orientation pour un budget global qui doit avoir du sens mais aussi de la souplesse pour pouvoir arbitrer les projets en fonction des aléas. Le premier biais est que lorsqu’on réalise cet exercice, on propose des enveloppes et, ce qui doit arriver arrivera, le manager en charge d’une enveloppe considèrera qu’il a exactement le chiffre qui est inscrit dans le budget. Donc, au mieux, il va dépenser tout le budget même si le projet peut coûter deux fois moins cher ou pire, s’il doit coûter deux fois plus cher… Bien sur, il existe quelques pratiques qui permettent de contrôler cette situation, comme de réserver une poche budgétaire, le budget du DSI, qui permettra de couvrir les coups durs (5 à 15%). Ma préférence va à un pilotage mensuel (au pire trimestriel) permettant de redéfinir et de communiquer fréquemment les priorités et les évolutions des enveloppes budgétaires.

Le chiffrage initial 

Car il en faut bien un, j’en suis le premier convaincu. Il est important de savoir s’il est intéressant d’investir, de savoir si le jeu en vaut la chandelle, s’il y a un potentiel retour sur investissement. Il faut bien se poser la question « Combien peut bien nous coûter la construction de ce produit/service/application? »
Plusieurs techniques existent, mais je vais en décrire uniquement trois que j’ai le plus souvent utilisées.

La technique de l’ingénieur
Dans cette technique, vous découpez votre projet en grandes fonctionnalités, puis vous décomposez chaque fonctionnalité jusqu’à arriver à des tâches unitaires, que vous estimez Simple, Moyenne ou Complexe à réaliser. En fonction de la nature du langage de programmation, de l’architecture, de l’âge du chef de projet, vous allez définir un nombre de jours.homme à chacune des catégories (S/M/C). Vous pouvez même appliquer des poids de complexité pour atténuer ou amplifier certains phénomènes (par exemple, si vous avez un nombre de fonctionnalités identiques, vous pourrez gagner du temps pour les réaliser en industrialisant le processus).
J’ai participé à plusieurs exercices de ce genre mais un seul retient mon attention tellement il est significatif de ce type de méthode. Lorsque j’étais consultant dans une grande SSII réputée pour son sérieux (totalement justifié en l’occurrence), une méthode de ce style a été mise au point parce que des écarts importants avaient été observés entre le chiffrage des projets au forfait et leurs réalisations effectives. Et cela, rarement au profit de l’entreprise… Le but était de proposer une méthode permettant de se rapprocher au plus proche du Chiffre exact. Afin de calibrer la méthode, il a été demandé à 3 manageurs de projets expérimentés (à eux trois, cela dépassait allègrement les 60 ans d’expérience!) de chiffrer avec cette méthode un projet qui avait d’ailleurs déjà été réalisé dans l’année. Donc, ils en avaient tous une connaissance suffisante. A la sortie, le plus optimiste était à 800 j.h et le plus pessimiste à 2400 j.h. 3 fois plus! Qui a tord, qui a raison? Je vais y répondre par la suite.

La technique de la comparaison 
Une autre technique consiste tout simplement à comparer le projet que vous devez réaliser avec un projet que vous avez déjà réalisé et qui y ressemble (un peu). Avec bon sens, vous pouvez évaluer si vous pensez que le projet sera globalement plus ou moins compliqué, que le contexte est plus ou moins favorable, que le projet comporte plus ou moins de risque. Vous remuez le tout et vous sortez un chiffre.

La technique par l’équipe type
La troisième technique consiste à définir l’équipe type que vous pensez avoir besoin pour faire le projet. Si par exemple, je pense avoir besoin d’une équipe composée d’un chef de projet fonctionnel (product owner), un chef de projet technique (scrum master), un technical leader et de 3 développeurs pendant 6 mois, alors cela me fait entre 600 j.h et 700j.h.

Comparer les estimations

Je n’ai pas réellement de préférence sur les techniques de base présentées précédemment même si j’utilise de moins en moins la première technique, et que je privilégie plutôt la combinaison des deux dernières. Surtout, j’essaie de challenger mon chiffrage en demandant à d’autres personnes de le faire aussi, dans leurs coins, puis de comparer nos résultats.

Une estimation est prévisionnelle 

Je répète : une estimation est prévisionnelle! Cela reste donc une ESTIMATION! Et, par définition, les estimations sont toujours fausses, même si elles sont nécessaires. S’il existait une méthode scientifique pour faire un chiffrage, cela se saurait maintenant! De plus, elle est PREVISIONNELLE, ce qui veut dire que c’est la meilleure estimation que l’on sait faire au moment où on l’a fait. En fonction des circonstances, cette estimation peut tout à fait changer et c’est bien normal. Et pourtant…

La planification initiale

Une fois chiffré, on peut se lancer dans la planification initiale du projet afin
La méthode que vous allez utiliser pour votre projet, quelle soit agile ou en cascade va bien sur impacter le rythme du projet mais ne devrait pas nécessairement impacter votre planning initial. En effet, dans un planning initial, il parait important de définir les jalons, les livraisons importantes de votre projet/produit/service/application. Depuis quelques années, les méthodes agiles et lean ont d’ailleurs largement influencés la construction de ces planning initiaux en proposant de commencer par un MVP (Minimum viable product), l’ensemble minimum des fonctionnalités qui permettent de mettre en production et de voir si le produit trouve son public. Evidemment, cette approche est tout à fait adaptée pour un service Internet et un peu moins pour une application de gestion, meme si on peut toujours s’en inspirer pour réduire le time to market et se concentrer sur les 20% des fonctionnalités qui sont utilisées dans 80% des cas.

Planifier avec « pragmatisme »

L’art de la planification est pourtant simple :
– faites un premier chiffrage (timeboxé)
– affinez avec un cadrage projet qui précise les éléments clés du projet : la vision, le périmètre, l’architecture de la solution (fonctionnelle et technique), l’organisation (méthode et compétences requises), les risques
définissez dés le départ la fréquence à laquelle vous allez réévaluer le planning et les estimations du projet -> c’est la clé
– staffez l’équipe et commencez à travailler
– au bout de quelques semaines (itérations?), révisez votre planning et votre chiffrage 
– ajustez en conséquence et informez vos sponsors
continuez et recommencez 

«  Toi, chef de projet, fais des plannings réalistes et laisse aux responsables le soin d’arbitrer. » 

Et pour finir sur une note positive, des études scientifiques démontrent que les personnes qui évaluent le mieux sont soit déprimées soit régulièrement pessimistes 😉

Quelques références de livres qui m’ont influencé sur ce thème :

Manage It! - Johanna Rothman

Manage It! – Johanna Rothman

The Mythical Man-Month - Frederick Brooks

The Mythical Man-Month – Frederick Brooks

Behind closed doors: Secrets of Great Management  - Esther Derby & Johanna Rothman

Behind closed doors: Secrets of Great Management – Esther Derby & Johanna Rothman

Waltzing with bears : Managing Risk on Software Projects - Tom DeMarco

Waltzing with bears : Managing Risk on Software Projects – Tom DeMarco

Quality software Management: Systems Thinking - Gerald M Weinberg

Quality software Management: Systems Thinking – Gerald M Weinberg

Psychologie sociale pour managers - David G Myers

Psychologie sociale pour managers – David G Myers