Pourquoi les projets finissent-ils si souvent en retard ?
Construire un immeuble. Sortir un site web. Créer un logiciel. Terminer n’importe quel projet lambda dans n’importe quelle entreprise.
Pourquoi ces projets finissent-ils si souvent en retard ?
Pourquoi est-ce qu’on dépasse aussi souvent la date limite que l’on s’est fixée ? Alors qu’à la base, on était tous d’accord sur cette date ? Qu’elle paraissait raisonnable ?
La réponse à cette question est assez évidente pour les personnes qui ont un peu d’expérience dans la gestion de projet.
Ou pour les personnes qui ont eu l’occasion de travailler dans l’informatique, le web, la construction et tous ces secteurs où, finalement, le retard dans les projets, eh bien… ça fait un peu partie du décor.
On sait qu’il faut vivre avec.
Mais, à force d’avoir des discussions avec des gens qui ne sont pas dans ces situations, je me rends compte que, pour le reste du monde… ça paraît complètement aberrant.
On finit par se dire que les responsables de ces retards sont paresseux. Ou incompétents, négligents… ou même, tout simplement, malveillants.
Alors qu’en réalité, il y a des raisons toutes bêtes, bien connues, derrière la grande majorité de ces retards.
J’aimerai vous partager l’une des meilleures explications que j’ai jamais lue.
Elle m’est venue il y a plusieurs années d’un chef de projet en informatique qui, dans un forum, essayait d’expliquer aux autres participants avec un exemple concret.
(Je ne retrouve malheureusement plus le message en question, donc pardon par avance pour la paraphrase)
Imaginez que vous décidiez un jour de faire une grande randonnée en vélo
Votre meilleur ami, qui a récemment déménagé pour retourner vivre près de sa famille en Corse, vient de vous inviter pour sa pendaison de crémaillère. Il vous propose aussi de passer la semaine suivante chez lui, pour profiter du beau temps du mois de juin.
En raccrochant le téléphone, vous et votre conjoint réalisez que vous avez la même idée un peu folle en tête : chéri, et si on y allait en vélo ?
Cela fait des mois que vous rêvez de faire une grande randonnée en vélo à deux.
La saison serait idéale : ensoleillée, mais pas trop chaud. Juin est littéralement le seul mois de l’année où vous pourrez tous les deux vous libérer du boulot et poser quelques semaines de congés bien méritées.
Toutes les conditions sont réunies. C’est un signe ça, non ? Allez, on se lance.
Au programme :
- Vu la distance et sachant que vous pouvez probablement avaler 70 km par jour, vous calculez qu’il faudra pédaler 10 jours pour faire tout le trajet
- On profitera de la route pour passer chez de la famille faire un petit coucou
- On prendra le ferry à Marseille pour Ajaccio
- De là, dernier morceau tranquille pour arriver chez l’ami Thierry.
Et là, ce sera fiesta. Puis une semaine de repos au calme, en bord de mer. Retour peinard en avion.
Let’s go
Le jour J, vous partez avec les lunettes de soleil, le visage tartiné de crème et un gros sourire sur le visage.
La journée avance, le soleil brille et vous avalez de la route. C’est physique, mais vous gardez le moral : le plaisir de l’exercice, l’excitation de cette aventure, le challenge que vous êtes en train de relever…
A la fin de la première journée, vous êtes tout de même un peu déçu. Vous n’avez fait que 51 kilomètres sur les 70 que vous aviez prévu d’avaler le premier jour.
Mais, bon, c’est la première journée, il faut le temps de trouver son rythme. Pas de quoi s’inquiéter.
A la fin de la deuxième journée… vous n’avez fait que 52 kilomètres sur 75.
Aïe.
Bon. On est raisonnable et capable de reconnaître quand on a fait une erreur. On pensait pouvoir avaler facilement les 70km par jour, mais on peut-être eu les yeux plus gros que le ventre.
Pas de soucis. On va juste modifier l’itinéraire. On renonce à quelques détours et on passe un coup de fil à tata Germaine pour lui expliquer que, en fait, on ne pourra pas passer ce coup-ci, mais qu’on se rattrapera sans faute aux prochaines vacances.
Jour 3. Minute. On est déjà le 3ème jour, là. Avec le plan revu, aurait du dépasser ce bled hier… on arrive que maintenant ?
Ok, on a raté quelque chose.
C’est vrai que maintenant, en zoomant sur la carte, vous vous rendez compte que la belle ligne droite qui relie le départ et l’arrivée… est en fait pleine de coudes, de tournants, de zig-zag voire parfois de détours pour contourner un obstacle non traversable à vélo.
Ce n’est pas 700 km que vous allez pédaler, mais plutôt 900.
Ok. On se motive. On va quand même essayer de faire 70 bornes par jour.
Jour 4. Bon, c’est la cata. Votre conjoint s’est blessé à la cheville à peine 10 kilomètres après le départ. On a bien essayé d’avancer vaille que vaille, mais il faut se rendre à l’évidence : aujourd’hui, ce sera repos.
Jour 6. On avance, on avance. Mais pas assez vite. On réalise un peu tard qu’on avait pas pris en compte le vent et le dénivelé dans la nouvelle estimation.
On essaye de revoir encore une fois l’itinéraire pour trouver des raccourcis et on va se coucher ce soir là en se disant qu’à partir de demain, on va vraiment “mettre la gomme”.
Jour 9. Il faut se rendre à l’évidence : on arrivera jamais à temps chez Thierry pour la pendaison de crémaillère.
Il faudra au moins deux jours de plus que ce qu’on avait prévu au départ. Et encore : si aucun accident ne se produit.
On fait une pause pour peser le pour et le contre, en bord de route, autour d’un jambon fromage mouillé (il pleut depuis deux jours).
Oui, on pourrait laisser tomber. Oui, on pourrait trouver une autre solution pour se faire transporter. Mais on ne va pas baisser les bras quand même. Ce n’est pas nous, ça. On est des battants. Ce challenge, on l’assume jusqu’au bout.
On appelle Thierry et on lui explique la situation. On s’excuse, on va malheureusement rater la crémaillère, mais on sera là sans faute pour passer la semaine ensemble.
Thierry, compréhensif qu’il est (et aussi un peu admiratif du défi qu’on s’est lancé), nous pardonne de bon cœur en riant et nous souhaite bonne chance. Il nous attend avec de bonnes bières et de la charcuterie locale qui va nous en mettre plein la vue.
Jour 12. On arrive enfin à Marseille ! Malheureusement, il n’y a pas de ferry demain et on est arrivé plus d’une heure après le dernier départ de la journée. Bon, eh bien, on dirait qu’on va visiter la ville.
Jour 15. Avec le dénivelé, on a finalement mis deux jours au lieu d’un seul pour rejoindre Thierry.
Bilan mitigé de l’aventure : on est fier du challenge accompli, mais le plan “Rejoindre à temps Thierry pour la pendaison de crémaillère” est à l’eau. Et on ne sera resté au final que 2 jours chez lui.
La raison numéro 1 qui fait capoter les projets, c’est que le plan de départ ne reflète jamais la complexité de la réalité
Le seul moyen d’avoir une estimation précise et de connaître avec certitude la date de fin d’un projet, ce serait d’avoir un plan qui tient compte d’absolument :
- Chaque micro-tâche nécessaire pour réaliser le projet
- Tous les accidents qui peuvent se produire en cours de route.
Sur les projets “simples”, c’est presque possible.
Reprenons l’exemple de la randonnée en vélo : on aurait pu avoir une estimation beaucoup plus précise avec un peu de préparation.
1/ En planifiant exactement l’itinéraire, au mètre près.
Plutôt que de tracer une ligne droite entre l’arrivée et la destination, on pourrait prendre un logiciel type Google Maps et tracer le parcours précis, pour vérifier la distance exacte. Et le dénivelé.
(Merci Google Maps, parce qu’à l’époque des cartes, ça n’a rien de très fun)
2/ Se faire une idée précise de la distance qu’on sera réellement capable de parcourir chaque jour.
- Faire plusieurs sorties à vélo sur au moins une journée
- Prendre en compte la fatigue (oui, on pourra faire XX km / jour les premiers jours… mais est-ce qu’on en sera toujours capable la 2ème semaine ?)
- Récolter les expériences et les avis de gens qui ont déjà fait ce genre de randonnées (sur les forums, dans les clubs, etc.)
- Demander l’avis des locaux qui connaissent le terrain (“Attention, le vent souffle fort ici en juin. Divisez par deux le nombre de kilomètres.”)
3/ Lister tous les accidents qui pourraient se produire.
- Prévoir pour chaque les précautions que vous pouvez prendre pour réduire au maximum les risques qu’ils se produisent.
- Prévoir un plan de contingence si malgré tout un accident arrive.
Bon, c’est déjà bien mieux, non ?
Mais deux remarques s’imposent tout de suite.
Primo, ce n’est pas très excitant comme travail, pas vrai ? (Mais on va y revenir plus bas)
Deuxio, c’est bien mieux… mais ce n’est toujours pas 100% infaillible.
Si on veut vraiment être irréprochable et 100% précis, il faudrait prendre en compte le type de route (on ira moins vite dans la boue que sur le goudron), la météo (on ne roule pas à la même vitesse sous la pluie avec un vent de 50km/h en pleine face), etc.
Bien sûr, on peut essayer d’intégrer au maximum ces facteurs. Sortir des analyses de la vitesse moyenne d’un cycliste en fonction du vent et du dénivelé.
Mais on va finir par atteindre une limite à ce qu’on peut prévoir (exemple type : la météo). Et le seul moyen de compenser sera de prévoir de la marge.
Sauf qu’une marge “sûre” va facilement doubler le temps de notre randonnée.
Et il est hors de question de partir sur 30 jours. Il faut qu’on se débrouille pour faire rentrer ça dans 10 ! (Là aussi, on en reparlera plus bas. Mais d’abord, un autre cas “simple”).
Prenons un deuxième exemple, plus compliqué, mais toujours de l’ordre du prévisible : la maison pré-fabriquée
Une entreprise fabrique le même modèle de maison pré-fabriquée depuis plusieurs années.
Les équipes ont plusieurs décennies d’expérience en construction derrière elles (avec ce modèle et avec d’autres).
Ce sont des gens biens, consciencieux, motivés par leur travail et fier de leur expertise.
Sur ce type de projet, il n’y a pas d’inconnues : on refait toujours les mêmes tâches, dans le même ordre, un projet après l’autre.
Et chaque “grosse” tâche peut être fragmentée en plusieurs tâches plus petites, qu’on est capable d’estimer précisément.
- Étape “Préparer le terrain” — Mission “Pose de la chape en béton” : X heures.
- Pose de la charpente…
- Finition de la façade…
- Création du jardin…
Hop. On fait le total du nombre d’heures nécessaires. On se laisse un peu de marge de sécurité. On vérifie tâche par tâche sur un planning qu’on aura tout ce qu’il faut chaque jour (personnes, ressources, livraisons, etc.) pour réaliser les tâches de la journée. Et roule ma poule.
Bien sûr, il reste toujours le risque d’accident. On est pas à l’abri d’un glissement de terrain ou d’une inondation, mais :
- On va prendre toutes les précautions que l’on peut et
- Il sera beaucoup plus facile d’aller voir le client pour lui expliquer un retard s’il y a une seule raison, majeure et imprévisible comme un accident naturel.
On est bons là, non ? Qu’est-ce qui pourrait arriver ?
Les surprises et les imprévus
“On vient de recevoir les murs. Apparemment, le fabricant a changé de méthode. Sur le papier, ça ne posait pas problème, mais on ne voit pas comment les monter.”
“L’entreprise de livraison vient d’appeler : ils ont eu une panne. Ils ne pourront pas livrer la charpente avant mardi.”
Plus le projet va comporter de micro-tâches, plus il y aura d’opportunités que quelque chose aille de travers. Et plus il y aura de “dépendances” entre deux tâches ou deux équipes.
Cela n’a l’air de rien, mais vous allez facilement vous retrouver avec une équipe qui se retrouve coincée plusieurs jours sans pouvoir avancer… parce qu’elle n’a pas les éléments dont elle a besoin.
“Bon, pas grave, on a toujours plusieurs projets en cours. On réorganise et on redistribue les ressources.”
Justement : cela va causer de nouveaux problèmes.
“- Fred, bonne nouvelle, on a enfin reçu les cloisons. Tu passes demain avec ton équipe ?
- Hein ? Non, pas possible. Je suis passé sur le projet des Martinez. L’équipe est bloquée pour les 3 prochains jours.
- Ça craint, on a déjà 5 jours de retard sur ce projet.
- Aie. Ecoute, au mieux, je peux t’envoyer l’équipe un jour la semaine prochaine et trois jours le mois d’après.”
La seule certitude, la seule chose que vous pouvez effectivement prévoir sur les imprévisibles… c’est qu’il vont se produire.
Seul un projet microscopique échappe à la règle. (Mais quel intérêt d’avoir une estimation sur un projet microscopique ?)
Ok. Maintenant, mettons de côté les surprises et les imprévus.
L’équipe
Toutes ces estimations que l’on a faites reposent sur une simple observation pour chaque tâche :
“En moyenne, les professionnels mettent X heures pour faire cette tâche dans ces conditions.”
Que se passe-t-il quand un nouveau rejoint l’équipe ? Ou un nouveau coordinateur ? Ou qu’un membre de l’équipe est malade ? Fatigué ? Déprimé ?
L’estimation est un idéal de temps qu’il faudrait tenir. Un impératif auquel on demande aux équipes de se plier.
Si vous avez déjà managé des gens, vous savez très bien que nous ne sommes pas tous égaux en termes de productivité et d’efficacité. Et que personne n’est efficace avec la même intensité tout au long de l’année (voir du mois, de la semaine ou de la journée).
Prenons un troisième exemple avec, cette fois-ci, un projet qui sort de l’ordre du prévisible : le développement d’un logiciel
Jusqu’ici, on a parlé de projets que l’on pouvait facilement découper en tâches. Et pour lesquels on pouvait trouver des indices fiables sur le temps que prend chaque tâche : “en moyenne, il faut X heures à un professionnel de niveau Y pour réaliser cette tâche dans des conditions Z”.
On est dans l’exécution : on sait exactement ce qu’il y a à faire et on a une idée fine du temps que cela va prendre.
Mais lorsqu’on entre dans des projets comme ceux qui impliquent du code (développer un site, une application, un service en ligne, un logiciel, etc.) on sort de l’exécution et on entre dans la recherche.
Lorsqu’un développeur commence un nouveau projet, il n’a absolument aucun cadre de référence sous la main qui pourrait l’aider à évaluer précisément combien de temps va prendre chaque étape.
Personne ne s’amuse à assembler le même logiciel dans les mêmes conditions.
Chaque micro tâche du projet est nouvelle. C’est une combinaison jamais vue avant de code, de technologie, de logiques, de fonctionnement, etc.
C’est difficile à imaginer pour la plupart des gens, car nous ne réalisons pas à quel point le code derrière un simple logiciel est en réalité complexe.
Au quotidien, nous nous servons de la partie “simple” de Facebook, Google, Windows et consort : l’interface. Nous ne nous rendons pas compte des milliers de lignes d’instructions qui sont nécessaires pour réaliser des actions qui apparaissent si simples à l’écran.
La meilleure comparaison que je puisse trouver, c’est : essayez de vous servir d’un texte de loi.
Imaginons que vous voulez lancer une startup avec un service un peu innovant et vous voulez vérifier la légalité de votre idée.
Techniquement, les textes de loi sont accessibles en ligne. En quelques clics.
Le premier texte que vous consultez… est en fait une liste de modifications apportées à d’autres textes de lois, antérieurs, sur le même sujet.
“Bon, ok, en gros, si je comprends bien le pavé que je viens de lire… La loi X ne s’applique pas dans ce cas là. Mais la loi Y et la loi Z peuvent s’appliquer, éventuellement, si je suis dans l’une des situations que décrit le texte R.”
Vous êtes donc partis pour aller lire :
- La loi X
- La loi Y
- La Loi Z
- Le texte R
Mais chacun de ces textes va être à son tour bâti sur d’autres textes et d’autres lois, eux-mêmes faisant référence à d’autres textes, dont vous allez devoir prendre connaissance.
Puis vous allez vous rendre compte que vous avez intérêt aussi à aller lire des décrets, des traités, des conventions, des circulaires, de la jurisprudence… bref, un panel d’autres sources qui vont avoir un impact sur ce simple renseignement dont vous avez besoin au départ : “Est-ce que j’ai le droit de lancer une entreprise qui vend ce type de service ?”.
Le problème dans le monde du développement est similaire : lorsqu’on ajoute une fonctionnalité à une application, il va falloir s’assurer qu’elle cohabite avec tout cet historique.
Oui, mais si on part de zéro ?
“Partir de zéro” signifie qu’il faut absolument tout coder. La moindre fonctionnalité, le moindre comportement. Y compris les plus basiques.
- Quand je saisie mon identifiant, et qu’il ne contient pas un “@”, un message d’erreur apparaît.
- Quand je clique sur “J’ai perdu mon mot de passe”, l’application vérifie que l’adresse est connue. Si elle est connue, l’application génère un lien unique et sécurisé, qu’elle m’envoie par email, et sur lequel je peux cliquer pour accéder à un écran qui me permettra de choisir mon nouveau mot de passe. Et…
Chaque comportement “basique” devra être prévu et programmé.
C’est la raison pour laquelle nombre d’applications sont créées à partir de “bibliothèques” qui contiennent toutes les fonctions nécessaires, déjà pré-codées.
Mais contrairement à l’exemple de la maison préfabriquée de tout à l’heure, vous ne pouvez pas vous faire livrer uniquement les pièces qui vous intéressent.
Ces bibliothèques sont trop riches et trop complexes. Les éléments qu’elles contiennent sont trop interdépendants. Vous devez donc installer la bibliothèque en entier. Et vous assurer que chaque élément que vous allez coder et ajouter par la suite fonctionne bien avec le reste.
Et même si vous partez véritablement “de zéro”, le problème sera toujours là.
Le simple volume de comportements, de logiques et de fonctionnements que vous allez coder va créer une gigantesque machine complexe.
Cela revient à programmer un organisme virtuel qui devra être capable de fonctionner sans erreur et de réaliser des tâches parfois complexes. Cela veut dire qu’il faudra penser chaque situation. Définir comment l’organisme doit se comporter. Et s’assurer qu’aucun des choix précédents que vous avez fait ne va entrer en conflit avec ce nouveau choix.
Dernière couche qui fait capoter les délais : le facteur “politique”
Prenez n’importe lequel des types de projets que l’on vient de voir (du plus simple à estimer jusqu’au plus complexe, où il est simplement impossible de faire une estimation).
Ajoutez-y une couche de politique.
Recette garantie pour se retrouver avec des délais intenables.
C’est le meilleur moyen d’avoir les yeux plus gros que le ventre.
1/ On va chercher à faire d’une pierre deux coups et à réaliser en un projet ce qui aurait dû être fait en deux.
Repensez à la randonnée en vélo : la tentation était trop grande. On a cherché à faire et la crémaillère et la randonnée. Alors que tout aurait été plus serein si on avait séparé ces deux évènements : un simple séjour chez un ami et une randonnée à un autre moment.
2/ On va essayer de négocier avec la réalité.
On va consulter un expert qui va nous affirmer catégoriquement que le projet ne peut raisonnablement pas être mené en moins de 40 jours.
Et une personne dans l’assemblée, qui n’a ni l’expertise, ni l’expérience, mais qui a le bon poste, ou les bons diplômes ou la bonne rhétorique va lancer un :
“Je ne comprends pas pourquoi il faut 40 jours. Moi ça me parait long. Dans mon ancienne boîte, on a fait plus compliqué en 20 jours.”
(Je suis à peu près certain qu’il y a une école quelque part qui forme ces gens : ils ont tous exactement la même posture, les mêmes tics de langage et la même attitude en apparence raisonnable et diplomatique, mais qui dégouline de condescendance.)
Au final, on décidera de “couper la poire en deux” et de partir sur 30 jours. “Ce qui est raisonnable”. Sauf que, non, ce n’est pas raisonnable du tout quand l’expert (= la personne qui a le plus de chances d’évaluer ce qui est réalisable) a déjà lui-même sous estimé la complexité.
3/ Parfois, les délais sont charcutés parce que la personne qui va tirer vers le bas a besoin de “vendre” le projet derrière.
A un client, à un N+1, etc. Et cette personne veut à tout prix réduire les délais pour que la vente se fasse (ou pour se simplifier la vie)… et tant pis si ce n’est pas réalisable derrière, ce n’est pas son problème.
Mais parfois, on a simplement affaire à des gens qui ont besoin de rouler des mécaniques. De montre qu’ils sont des winners. Qu’ils sont de ceux qui font “bouger les choses”.
Sauf que… négocier avec la réalité va seulement changer la date que l’on mettra en gros sur les documents. Pas la réalité du temps qu’il faudra pour réaliser le projet.
4/ On va se mettre d’accord sur une date limite… mais on va rogner sur les pré-requis derrière
Une fois que tout le monde est d’accord sur les délais, l’étape suivante, c’est que les experts tracent le plan. Budget, ressources, pré-requis indispensables pour que le délai soit tenable.
- “Une fois qu’on aura validé telle étape, on ne pourra pas revenir en arrière”
- “Il faudra qu’on ait tranché sur ce sujet à telle date”
- “On aura besoin d’au moins X ressources pour cette étape“
Malheureusement, ces pré-requis peuvent très facilement sauter avant même le début du projet.
- “Non, finalement on aura pas les ressources cette semaine.”
- “On ne sait pas encore quels cas on veut traiter exactement. Mais ça ne vous empêche pas de commencer.”
On se retrouve à devoir commencer le projet avec le même délai, mais sans les pré-requis pour que ce délai soit réaliste.
“- Attendez, on veut bien construire votre maison en bois, mais pour ça il nous faut du bois. Vous deviez nous fournir le bois le…
- Débrouillez-vous.
- Bah… Écoutez, je pense que je peux aller chercher du bois moi-même. Mais ça va prendre du temps. Et on en manque déjà pour…
- Débrouillez-vous.”
Je grossis le trait : dans les faits, cela se passe avec beaucoup plus de subtilité.
Des réunions que l’on fait sauter “parce qu’elles ne sont plus nécessaires, n’est-ce pas ?”.
Des intonations et des sous-entendus sur le fait “qu’il faut être agile”, “débrouillard”, “que tout le monde doit faire des efforts”. “Que dans l’équipe, on accepte que les gens qui trouvent des solutions, pas ceux qui n’ont que des problèmes”.
Certains décideurs sont très fort à ce petit jeu.
Et ils n’y voient d’ailleurs aucun problème : ils poussent, et si personne ne résiste en face, c’est qu’ils avaient raison. Que ce qu’ils demandaient était possible.
Ils ont simplement fait leur job qui consiste à “optimiser”, à “rendre plus efficient” et à “tirer 100% des équipes”.
Mais personne ne négocie avec la réalité.
En forçant les choses, on ne rend pas le projet plus réalisable. On a juste changé la “date officielle” avec seulement trois conséquences possibles.
- On ne tiendra pas la date.
- Les équipes vont se surmener.
- On va prendre des raccourcis que l’on paiera plus tard.
5/ On va se mettre d’accord sur une date limite et des ressources… mais on va continuer à ajouter et à demander plus pendant le projet (Scope Creep)
“- On est bon sur le projet X ? Ça avance bien ?
- On est pas trop mal pour l’instant. On a pas encore attaqué le plus gros, mais…
- Parfait. Bon, écoute, j’ai discuté avec le client, et il a besoin que l’on fasse des changements. Je t’envoie la liste.
- Hein ? Mais, c’est quoi ces changements ?
- Attend, il faut qu’on se débrouille là. C’est des changements pas très compliqués. Et le client y tient vraiment. Hum… (Visage de l’adulte qui se montre patient avec un enfant un peu lent qui refuse de comprendre une vérité pourtant très simple.) J’espère que tu te rends compte qu’on a pas vraiment le choix.”
C’est une grande spécialité des mauvais coordinateurs (chefs de projets, commerciaux, etc.) qui préfèrent déplacer le problème sur les équipes en interne plutôt que de guider fermement le client.
Qu’importe la “simplicité” des changements que l’on ajoute en cours de route : cela reste une surcharge par rapport à l’estimation. Si on ajoute, il faut estimer et décaler la fin du projet.
Mais le “Scope Creep” (c’est le nom officiel en gestion de projet) vient parfois de bonnes intentions voire des équipes elles-mêmes.
En cours de route, on pense à un léger changement qui apporterait énormément de valeur ajoutée. Il ne nous vient même pas à l’esprit de ne pas le faire.
Sauf que, mis bout-à-bout, ces changements finissent par peser. Sans compter qu’ils peuvent apporter des complexités.
“- Tu te souviens du module d’import des photos qu’on a ajouté ? Celui qui n’était pas prévu au départ ?
- Bien sur. L’interface est beaucoup plus cool. Au moins, comme ça, le client peut visualiser ses photos quand il les charge.
- Euh… je crois que ce module met le bazar dans le fonctionnement du module qui gère les fichiers. J’ai aucune idée de comment régler ça.”
Choix A : on recommence le module photo, comme prévu au départ (en espérant que le client comprenne pourquoi on est revenu en arrière)
Choix B : on essaye de fixer le bug (sans certitude sur “combien de temps cela va prendre” ou “est-ce seulement possible”).
6/ On va refuser de prendre des décisions (ou les reporter le plus possible)
Exemple type :
“On a besoin de développer une application pour que les équipes puissent envoyer un ticket quand ils ont un problème. On ne sait pas encore quel sera le process :
- Qui pourra déposer une demande
- Dans quels cas
- Ce qu’ils mettront dans leur demande
- Qui va intervenir ensuite et dans quel ordre
- Etc.
Mais il faut commencer à développer dès demain matin. On décidera plus tard.”
Remettons les choses en perspectives.
“- J’ai besoin d’un transport pour Berlin.
- Oh ? Ok. Combien de personnes ?
- On verra plus tard. Ecoute : je sais ce que tu vas me dire. Dans un monde idéal, tu aurais l’information pour commencer. Mais on ne sait pas encore, ok ? C’est compliqué. Il faut que vous commenciez à plancher dessus aujourd’hui. C’est vraiment urgent.”
Sauf qu’on est pas en train de parler d’un monde idéal, là : on est en train de parler du strict nécessaire pour commencer le projet.
Comment voulez-vous que quelqu’un planifie un transport sans savoir…
- Combien de personnes il faudra transporter ? (Est-ce seulement des personnes que l’on va transporter ?)
- Quelle est la priorité (Aller vite ? Se déplacer confortablement ? Pas cher ?)
- Quel niveau de ressources on est prêt à mettre ? (Location de voiture, train, avion…)
- Quand aura lieu ce transport ?
Au final, avec aussi peu d’informations, on pourrait aussi bien se retrouver avec un collègue qui va prendre sa voiture qu’avec un billet d’avion première classe.
On risque même d’avoir des surprises sur des “évidences”.
“- Bon, je t’ai fait une liste de toutes les combinaisons possibles et imaginables. Ca commence à 60 euros et…
- 60 euros ? Par mois ?
- Comment ça, par mois ? C’est bien un aller simple ?
- Mais enfin, tu le fais exprès ? C’est une navette que je veux. C’est évident qu’il nous le faut tous les mois !”
Non. Rien n’est jamais évident dans un projet. C’est pour ça qu’il faut se poser des questions en amont, car les hypothèses et les préjugés peuvent condamner le projet avant même qu’il n’ait démarré.
Il y a deux raisons qui poussent des interlocuteurs raisonnables et de bonne volonté à reporter le plus loin possible les décisions.
7/ L’urgence : il faut agir, pas réfléchir
Dans certaines situations en entreprise, il est très mal vu de demander du temps de réflexion. Cela peut déclencher des réactions presques allergiques dans la chaîne de commandement.
“Écoute, dans un monde idéal, on se serait posé et on aurait réfléchi. Mais là, on a vraiment pas le temps.”
Sauf que ce n’est pas la bonne solution.
“Mettre directement les mains dans le cambouis > Devoir revenir en arrière parce que l’on s’est planté > Essayer de comprendre ce qui n’a pas marché > Recommencer > Réussir”
Prend beaucoup plus de temps que
“Se poser les bonnes questions > Faire > Ajuster > Réussir”
8/ Peur ? Paresse ? Peu importe : refus d’être celui qui fait le premier pas
C’est une situation que j’ai souvent vue par le passé et qui m’a toujours surpris.
Elle se produit quand une personne qui a un besoin vient consulter pour la première fois l’expert qui va répondre à ce besoin.
Il y a souvent une incompréhension qui s’installe où les deux parties refusent de faire le premier pas.
“- J’en sais rien moi, de tes questions. Fais-moi une proposition !
- Attends, je peux vraiment pas t’aider. Tu sais pas ce que tu veux. Il faut que tu te poses sur ton projet et que tu réfléchisses à ce que tu veux.
- Mais je sais pas ce qui est possible. C’est ton boulot de me faire une proposition.
- Et je peux pas le faire si tu ne sais pas ce qu’il te faut.”
Dialogue de sourd.
Qui se produit en entreprise, entre un prestataire et son client… même dans une boutique.
“- Il me faudrait un vélo ?
- Lequel ?”
D’un côté, le demandeur s’attend à ce qu’on lui fasse un catalogue de tout ce qui est possible. Une sélection de solution pré-packagées qui vont, par magie, répondre à son besoin.
De l’autre, l’expert s’attend à ce que le demandeur ait le même niveau d’expertise que lui. Et soit capable de venir avec un cahier des charges complet de A à Z. Pour qu’il puisse l’analyser en une seule fois et lui faire un devis en retour.
Les deux, bien sûr, se trompent : ils sont convaincus que ce premier pas dans le projet doit se faire en une seule fois, par l’une des deux parties.
Alors que cette étape doit se faire à deux. Il faut prendre un moment ensemble pour échanger et se comprendre l’un l’autre. Se poser des questions.
Il faut que le demandeur confie tout ce qu’il sait sur le contexte du projet et qu’il avoue ce qu’il ne sait pas.
Il faut que l’expert donne des billes et aident à comprendre les sujets et les enjeux macros qui vont à priori le plus peser sur les décisions.
“- Ma direction veut qu’on se penche sérieusement sur le référencement. Faire monter notre site dans les résultats de Google. J’ai besoin d’aide : ce n’est pas mon coeur de métier. Je peux pas monter un plan seul. Tu peux m’aider ?
- Bien sûr. Tu as une idée du volume de résultats qu’ils ont en tête ?
- (Hésite) Je saurais vraiment pas te dire. On a pas fixé d’objectifs.
- Pas grave, pas de soucis. Mais toi, à priori, sans t’engager, qu’est-ce que tu en penses ? Qu’est-ce qui serait un résultat acceptable pour eux ?
- En gros, on est à 1200 visites / mois aujourd’hui. Je pense qu’ils veulent tripler ça d’ici la fin de l’année.
- Ok, très bien : c’est une très bonne base pour commencer à réfléchir. Alors, pour te donner un ordre d’idée de ce qui est réalisable…”
Mais ça demande de la confiance, de la transparence, pas d’égo, et du respect.
Une note positive pour terminer : oui, le problème est réel, mais il y a aussi des solutions.
Premièrement : être conscient de tous ces facteurs qui peuvent jouer dans un projet.
Garder en tête que nous autres être humains, nous sommes plutôt mauvais lorsqu’il s’agit d’estimer le temps réel que va prendre une tâche.
Que notre cerveau est limité, et que nous pouvons rarement estimer vraiment un projet en analysant chaque micro- morceaux.
Que certains projets résistent de toute façon à l’estimation parce qu’on a aucune base de comparaison sur laquelle s’appuyer.
Que des surprises vont se produire.
Que chaque surprise et chaque erreur d’estimation va augmenter le risque que l’on rate une “passerelle” dans le projet… et qu’on va se retrouver avec une équipe qui va se tourner les pouces sur le chantier, parce que la livraison a été retardée.
Que les gens ne sont pas des machines capables de livrer à un rythme constant.
Que la politique, l’égo ou les intérêts personnels peuvent très vite faire très mal à une estimation.
Bref ! Qu’une estimation, ce n’est jamais qu’une estimation. Que “Ce ne sont pas les équipes qui sont en retard, mais le planning qui est faux” pour reprendre les mots d’un excellent coach agile.
Deuxièmement : approcher les projets (surtout les projets complexes) de manière plus humble
C’est ce que s’efforce de faire la méthode agile.
Reprenons nos vélos. Cette fois-ci, avec deux changements importants.
Premièrement, on se met d’accord en amont sur ce que l’on attend de cette aventure. Sur la priorité. Sur ce qui est vraiment important pour nous ici.
- Faire ce challenge, se lancer dans l’aventure et pouvoir se dire qu’on a fait une randonnée en vélo de 10 jours.
On abandonne l’idée d’arriver chez Thierry dans 11 jours. (Si c’était vraiment, ce qu’il y a de plus important, on changerait notre fusil d’épaule et on prendrait l’avion.)
Deuxièmement, plutôt que d’essayer de planifier absolument chaque étape du parcours, on va plutôt planifier le premier tronçon : celui des 2 premiers jours.
C’est déjà beaucoup plus facile, non ?
On a une estimation assez fine de la météo
Analyser finement le trajet de 10 jours de parcours est irréalisable, mais 2 jours, c’est déjà beaucoup plus simple
Les erreurs (accidents de trajets, routes bloquées, retard, etc.) vont être beaucoup moins important
Prédire où l’on sera dans 10 jours est impossible, mais on peut se faire une idée assez fine de “où” l’on sera demain soir.
Ça ne veut pas dire qu’on tombe dans le court-termisme.
On a quand même une idée du “Où on veut aller” à la fin du périple. Idéalement.
Mais on ne cherche pas à prédire absolument comment tout le chemin va se dérouler… car on sait d’expérience qu’on arrivera pas à un niveau d’estimation utilisable. Et qu’on risque de prendre cette estimation fausse comme une vérité sacrée.
Une fois que l’on aura terminé ces deux jours, on aura une base solide (un morceau du projet déjà terminé) ainsi qu’un bien meilleur point de vue pour la suite du projet.
Parce qu’on aura appris des choses sur ce projet.
Sur notre rythme de progression.
Sur des hypothèses que l’on avait et qui vont se révéler fausses … ce qui va nous permettre d’ajuster intelligemment en cours de projet sans tout remettre en cause.
“En fait, oui, on voulait faire du vélo, mais ce qui nous plait vraiment, c’est les parcours en forêt. On veut faire le moins de vélo sur route possible. Vu la carte, on va changer finalement la destination finale, et partir plus vers le parc régional de…”
