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

Publicités

3 réflexions au sujet de « Monsieur le DSI, vous voulez des plannings réalistes? »

  1. Article intéressant. Le pragmatisme est une valeur sûre en gestion de projet 🙂 Par contre difficile d’itérer sur un planning dans le cadre d’une prestation au forfait. Mon expérience est que les dépassements sur les projets tiennent souvent à des facteurs exogènes (typiquement un manager qui veut rajouter son grain de sel). C’est pour cela que je fais en sorte d’engager le client le plus possible sur le planning au travers de livrables clairs et des points d’avancement réguliers. C’est trop facile sinon de se comporter en inspecteur des travaux finaux et de « péter » le planning.

  2. Merci Lucie pour ton feedback. Tu pointes du doigt plusieurs points très intéressants et qui me motivent à écrire de nouveaux posts pour les adresser plus largement, et toujours avec pour seule ambition que de ne partager ma propre expérience, qui m’a amené d’ailleurs à me retrouver des deux côtés de la « barrière ».

    Je retiens donc
    – comment itérer sur un planning quand on se trouve dans un cadre contractuel et forfaitaire? Cadre de la confiance ou de la méfiance?
    – comment gérer les facteurs exogènes? Est-ce qu’un manager est légitime à venir ajouter « son grain de sel »? Quelles stratégies pour s’adapter?
    – comment engager un client et faire en sorte qu’il se sente plus « cochon » que « poule »? On en profitera pour discuter de l’omelette aux lardons 😉

    A très bientôt donc!

  3. Ping : De l’importance du cadrage de projet | Le buzz du Buzz

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s