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

Avec internet il y’a plus de monde aux enterrements!

Beaucoup de questions se posent sur l’impact des nouveaux moyens de communication sur nos sociétés.
Est-ce un progrès ? Est-ce que cela ne conduit finalement pas à éloigner les gens? A ne plus avoir de rapports physiques mais uniquement virtuels?
Michel Serres nous dit pourtant que nous avons la chance de vivre la troisième plus grande invention de notre histoire depuis l’écriture et l’imprimerie. Et qu’il est donc normal d’observer des changements sociétaux importants.
Pour ma part, et avec beaucoup d’humilité, je vais simplement partager trois exemples de changements positifs observés récemment.
Tout d’abord, l’impact qu’a pu avoir un réseau comme Facebook sur mon épouse. Elle est américaine et se retrouve donc loin de sa famille, de ses amis, qui sont de toute façon répartis aux quatre coins des Etats-Unis. Facebook lui a bien sûr permis d’échanger à distance, de trouver une certaine instantanéité, de retrouver même des connaissances qu’elle avait perdues de vue. Surtout, et c’est ce point que je voudrais mettre en avant, ils se retrouvent ensemble à la première occasion et la discussion est finalement plus fluide, presque plus évidente : «  Oui, j’ai vu les photos de la graduation d’Elizabeth.. », «  ton nouveau chien est magnifique », « tu as vu que notre prof de danse était gravement malade » …
Autre exemple, tout aussi positif, même si le contexte est malheureusement plus douloureux. Un très bon ami d’enfance est victime d’une maladie dégénératrice… Sans internet, le tchat, il serait coupé du monde. Sa condition ne lui permet pas de se déplacer facilement et il est plus facile pour lui de chater que de parler au téléphone par exemple. Cela le fatigue beaucoup moins. En faisant des recherches, en croisant les données, les témoignages, il a pu trouver des informations sur sa maladie, mieux comprendre, et parfois même apporter des éléments que les docteurs eux mêmes n’avaient pas (ou plus) en tête. Cela l’aide au quotidien à accepter la dure réalité de sa maladie. Surtout, il a pu entrer en contact avec des personnes qui souffrent de la même maladie; ils en discutent librement, se rassurent, partagent ce qui marche pour l’un, explique ce que l’autre ressent… Ils peuvent le faire tout le temps, en toute simplicité alors qu’il est si difficile pour eux d’échanger sur leur maladie avec leurs proches, leurs familles, leurs amis…

Enfin, le dernier exemple vient de ma mère. L’autre jour, elle me lance « ah oui, toi qui travaille là-dedans, ben, tu sais l’Internet, c’est vraiment super quand même. Cela me permet de communiquer une information d’un seul coup avec tous les membres de la Retraite Heureuse! »
«  Oui, je sais maman, cela s’appelle le mail. C’est fait pour ça. »
«  Oui, et bien, grâce a l’Internet, il y a plus de monde aux enterrements! »
« Quoi?? »
«  Ben, oui. Avant les gens se voyaient tout le temps, ils étaient proches. Dans les dernières décennies, la distance s’installe et on se voit moins au quotidien. On se voit aux réunions, repas, mais plus tous les jours… Du coup, il y avait moins de monde aux enterrements… Maintenant, quand il y a un enterrement, j’envoie un mail et il y a au moins 100 personnes qui viennent! »

Et vous, avez-vous des exemples à partager?

Gustave_Courbet_-_A_Burial_at_Ornans_-_Google_Art_Project_2

Il n’y a pas d’ingrédient secret!

Mais un bon leader peut en créer l’illusion!

« There is no secret ingredient. To make something special, you just have to believe it’s special! », 
Non, cette phrase n’est pas de Eckart Tolle ou du Dalaï Lama mais de Kung Fu Panda, ou pour être plus précis du père de Kung Fu Panda (enfin, c’est pas vraiment son père mais ca, Kung Fu Panda ne le sais pas, chut!!), le cuisinier qui fait une soupe tellement appréciée que tout le monde pense qu’il utilise un ingrédient secret.
http://www.youtube.com/watch?v=K7DnFGdqT8c

Lorsque j’ai revu Kung Fu Panda pendant les fêtes de fin d’année, tout de suite, cette phrase m’a fait penser à ce que j’ai pu observer en accompagnent des équipes sur des projets IT. Et aussi, au rôle particulier qu’un leader pouvait jouer auprès de ces équipes. Bien sur, comparaison n’est pas raison, et la mienne de comparaison n’est peut-être pas fabuleuse mais je m’explique quand même (et après tout, je fais ce que je veux, non?).

En réalité, il arrive fréquemment que les équipes se focalisent sur les freins d’un projet. N’avez vous jamais entendu : « Mon dieu, on ne va jamais y arriver! », « On n’aura jamais le temps! », « On manque de ressource! », «  Le projet est trop gros! », « Le sujet n’est pas clair! » ( choisissez ou ajoutez votre « excuse! » )

Cette peur peut paralyser une équipe entière

Comment l’éviter?
Beaucoup de méthodes proposent de détailler le projet, voire de le détailler encore plus, de découper en tâches plus fines, de planifier, planifier, planifier… Ca peut aider.

Personnellement, j’ai trop observé de temps perdu à vouloir trop détailler en amont, demander à des gens qui ne savent pas (objectivement) décrire des « spécifications détaillées », de planifier pour rien… Je préfère une approche beaucoup plus pragmatique, initialisée par un cadrage minimal (tout du moins time boxé), suivi d’une mise en action immédiate et d’un process d’amélioration continue permettant l’ajustement. Ca donne donc:

On priorise -> On choisit -> On fait -> On livre -> On analyse -> On ajuste -> On recommence

Bref, si vous n’avez toujours pas compris de quoi je parle, c’est bien des méthodes agiles.

Mais, cela n’est parfois pas suffisant. Le process, la méthode sont importants mais si on y injecte l’ingrédient secret, c’est encore mieux. Et cet ingrédient secret, pour une équipe, c’est avoir la certitude qu’elle peut s’appuyer sur un manageur agile, un leader, capable de la soutenir dans les moments importants.

Ce leader doit être capable de
– Ecouter de manière active (vraiment!) les remontées de l’équipe
– Rassurer quand l’équipe se pose des questions
– Protéger l’équipe de tout le bruit et les perturbations qui l’entourent afin qu’elle se focalise sur ce qu’elle a de plus important à faire

En gros, être la courroie de transmission avec le top management, en mettant ce dernier devant ses propres responsabilités lorsque cela est nécessaire («  vous demandez le beurre et l’argent du beurre! Choisissez ce qui est le plus important pour vous! »).

Aux yeux de l’équipe, ce leader devient l’ingrédient secret

Fort de ce soutien, et une fois la mise en marche enclenchée, l’équipe va prendre confiance en elle et éviter de perdre du temps sur des sujets sur lesquels elle n’a pas de prise.

Piloter par les risques: la règle de survie du DSI

Il y a quelques années, j’ai eu la chance de travailler pendant de nombreux mois auprès d’un DSI d’une grande assurance. Il m’a appris qu’en tant que directeur, on ne peut pas être présent sur tous les dossiers. 

A l’époque, j’étais consultant chez Octo et je faisais une mission stratégique de positionnement de la cellule d’architecture dans l’organisation de cette entreprise. Nous avions organisé une présentation préparatoire à la restitution finale de cette mission devant le board. L’ensemble des directeurs impliqués sont venus à la réunion mais pas le DSI… Le lendemain je le croise à la cantine. Je me présente et je lui demande s’il souhaite une présentation individuelle. Ça réponse m’a alors laissé sur le cul et elle continue de m’influencer : « Non, ce n’est pas la peine. Je sais que vous avancez bien et cette mission est bien suivie (par un de ses directeurs). J’ai beaucoup de sujets à suivre, alors je gère par les risques. Vous, vous êtes en contrôle, donc ce n’est pas la peine que je perde du temps. »

Wow!!

Et effectivement, au fil des semaines et des mois pendant lesquels j’ai pu accompagner ce client, j’ai observé que cette réponse n’était pas juste des mots mais bien une réalité. Vu l’activité importante à laquelle il faisait face, c’était certainement une règle de survie!

2899230443_dbf43dbeed_o