→ Comment j'ai planté mon premier projet et ce que je ferai autrement ★ Chef de Projet Malin

Comment j’ai planté mon premier projet et ce que je ferais autrement

Dans cet article, je vous raconte en détail mon premier projet en tant que chef de projet et ce que j’en ai retenu sur le moment.

Quand je serai grand, je serai chef de projet

Automne à Paris. J’arrive au boulot comme tous les matins quand le directeur des opérations me met la main dessus et demande à me voir. Je le suis dans son bureau et il m’annonce la couleur :

« Jean-Philippe, il y a un projet qui démarre pour France Telecom et on a besoin de quelqu’un pour prendre le lead sur le projet. Tu travailleras avec David (nom changé mais je suis sûr qu’il se reconnaîtra :-)) pour la partie technique.  Il y a une réunion de prévue demain avec le client pour « poser les choses. Il vient de province exprès pour ça. »

Mince alors, je vais faire de la gestion de projet ! Je sors du bureau en bombant le torse et je vais jeter un oeil à la proposition commerciale associée. Projet au forfait, 22 jours et libellé de projet à coucher dehors :

« Elaboration d’une solution automatisée d’amélioration et de contrôle de la qualité des données référentielles »

J’en saurai plus pendant la réunion, qu’on m’a dit. Ah bon. La technologie du projet n’est pas bien connue par David apparemment.

Réunion le lendemain comme prévu – j’ai mis ma plus belle chemise – et on se retrouve le client, David et moi dans une salle sans fenêtre avec des feuilles de paperboard accrochées partout aux murs après 2 heures d’explications. Le client nous a fait part des « idées » qu’il avait en vrac dans sa tête et de ce que l’application devait faire.  A la sortie, David monte un peu en stress  quant à la complexité du « truc », j’essaie de me montrer rassurant en lui disant que j’allais tâcher de cadrer tout cela dans les spécifications.

La lettre au Père Noël du client

Les jours passent et les spécifications avancent, je fais en sorte que le contenu tienne dans le budget imparti et commencent alors les allers-retours avec le client. Pour résumer, chacune de ses remarques commence par « Ce serait bien si ça pouvait faire … ». Je tâche d’être créatif dans mes réponses :

Ok j’ai pris en compte mais je ne sais pas si ça va tenir dans le budget …

Ah oui c’est une fonctionnalité complexe que vous voulez là quand même, vous ne trouvez pas ?

Ah oui ce n’est pas trivial tout de même, on n’avait pas vu ça quand on a chiffré ..

J’ai donc lâché sur certains points et j’ai botté en touche sur d’autres en disant qu’on verrait plus tard. Côté budget et planning des spécifications, il commence à être temps de valider pour passer à la réalisation et éviter que les spécifications ne durent éternellement. Seulement voilà, le flux continu des retours de type « Ca serait bien » ne cesse pas, il s’intensifie même. David est en attente de pouvoir réaliser donc en stand-by, en intercontrat, ce qui ne plaît pas à la direction. Je décide donc d’attaquer la réalisation sur ce qui est déjà écrit pour occuper David et prendre un peu d’avance sur la suite. Le client n’a toujours pas validé les spécifications.

J’apprends à cette étape que le chef de mon client connaît le n+2 du directeur des opérations. Ca me met un peu la pression mais sans plus.

David lui, ne veut pas lire les spécifications car il ne veut pas ouvrir de fichier Word, c’est un logiciel Microsoft et c’est « le mal absolu ». J’essaie de le convaincre d’ouvrir le fichier et en même temps je lui ré-explique à l’oral le contenu des spécifications histoire qu’il avance un peu quand même.

Les spécifications : l’Histoire sans Fin …

Les jours passent, les développements avancent et les spécifications ne sont toujours pas validées. A un comité de suivi, on soulève le point et on arrive à la conclusion qu’un prototype va être livré pour tester un peu la bête et « qu’on verrait ensuite ». A partir de là, le cycle infernal des « Ca serait bien que … » s’est encore amplifié, on écrit les spécifications en même temps qu’on développe.

David continue à me demander le contenu des spécifications et voit que ça n’arrête pas d’évoluer. Ce qui est développé ne fonctionne pas bien, ce qui marchait hier ne marche plus aujourd’hui. La technologie, pourtant proposée par nos équipes, n’est pas idéale et surtout non maîtrisée. David commence donc à monter en pression et moi aussi … Ca explose deux-trois fois entre nous à ce moment-là.

On a commencé à tenir un fichier Excel des « problèmes » sur l’application du point de vue du client, les « Ca serait bien .. » des emails deviennent donc des lignes dans un tableau récapitulatif. Le client le met à jour régulièrement avec les cas qu’il a en tête et m’envoie une nouvelle version du tableau tous les jours. Tableau que je mets à jour également de mon côté et que j’ai du mal à fusionner avec les nouvelles moutures du client ..

En voyant les retours du client, David monte encore en pression, il est sur le point de péter les plombs. Un jour, je reçois un email du client, je le lis à David pour qu’il en tienne compte dans ses développements mais il commence à s’énerver. J’essaie de le calmer mais il me demande le numéro de téléphone du client pour l’appeler et lui dire qu’il fait ch**r à en vouloir toujours plus .. Il a le téléphone en main et essaie de voir par dessus mon épaule pour lire le numéro de la téléphone du client dans la signature de son email … Il finit par se calmer et retourne avancer sur la réalisation.

Excel, ton univers impitoyable …

Je commence à mettre dans la boucle le directeur de projets car je prends conscience que je n’ai plus le contrôle. Il me propose notamment d’ajouter une colonne dans le fichier Excel pour préciser s’il s’agit d’une anomalie ou d’une évolution et recadrer le débat là-dessus avec le client. Je commence à discuter de ce point-là avec le client mais il ne veut rien entendre. Pour lui ce qui compte c’est que ça marche comme il veut.

Le tableau Excel atteignant près d’une centaine de lignes, on décide d’organiser une réunion physique pour faire une revue de ce qui a été réalisé. Elle est planifiée un mercredi après-midi à 13h dans un bâtiment d’une zone industrielle en banlieue parisienne. Et là, commencent 4 heures de discussions sur chacune des lignes du tableau des « problèmes » pour savoir s’il s’agit d’une anomalie ou d’une évolution. Je lui réexplique le principe : si cela ne marche pas comme écrit dans les spécifications c’est une anomalie, si le comportement attendu n’est pas décrit dans les spécifications c’est une évolution.

Pas moyen de se mettre d’accord car le client ne veut rien entendre et ne veut pas discuter de ça, il veut avancer pour que ça marche comme il le souhaite. J’ai hâte que la réunion se termine. 17h45, on s’arrête là, j’en ai marre, j’ai le cerveau qui ne veut plus tourner. Je quitte le bâtiment d’un pas rapide, les dents serrées et me surprends à crier « Aaaaaaaahh » en pleine rue. Entraînement de volley dans la foulée, la balle a pris cher ce soir-là ..

Réveil laborieux le lendemain lorsque le réveil sonne. Pas moyen de bouger, j’ai un mal de dos incroyable qui me cloue au lit. Tout mon corps est crispé. Je préviens mon chef que j’ai un problème et que je vais voir le docteur. Ce dernier m’annonce un lumbago, me donne 2 jours d’arrêt et attire mon attention sur le stress au boulot. Mon chef n’en revient pas et assure l’intérim. Il m’avouera ensuite qu’il n’avait rien vu venir.

Et ça continue, encore et encore, c’est que le début d’accord, d’accord …

Le budget de 22 jours est explosé, nous venons de dépasser les 50 jours. Le directeur des opérations s’implique complètement dans le projet et obtient un deal au téléphone : on réalise un lot défini de fonctionnalités et après on arrête le projet. Accord trouvé ! Les développements sont réalisés puis testés mais le client revient encore sur les autres fonctionnalités du tableau excel de suivi. Petit aller retour avec le n+2 de mon chef pour savoir si on continue ou pas  le massacre. Verdict : on continue. On définit un deuxième deal sur un autre lot de fonctionnalités. Accord trouvé donc et tracé à nouveau. Une fois livré, le client revient à la charge sur d’autres fonctionnalités encore …

Réunion téléphonique avec le client, son chef, mon chef et moi-même. On n’arrive pas à trouver d’accord, on leur explique qu’on a multiplié le budget par 4, ils nous rétorquent que c’est pourtant la démarche projet proposée dans notre offre qui veut ce mode de fonctionnement. Bref, rien de concrêt à l’issue de la réunion. Et bien sûr, côté facturation, puisque rien n’a été validé depuis le début, rien n’a pu être facturé plusieurs mois après le début du projet.

Projet difficile à résumer en un article, de nombreux échanges ont lieu encore ensuite pour essayer de figer le périmètre, obtenir les informations pour corriger les anomalies, etc. 5 mois après le début de projet, un ultime plan d’action est proposé au client pour continuer le projet. Autrement, le projet sera arrêté en l’état. Les délais de réponses s’allongent, les disponibilités s’amenuisent et le projet est abandonné par la force des choses. Le projet est clos à 99,25 jours.

Retour vers le futur

Alors hors contexte, et avec le recul et l’expérience, les erreurs peuvent paraître évidentes, et puis c’est toujours facile de dire après coup qu’il aurait fallu faire autrement, que c’est évident que ça allait se planter, etc. C’est comme voir les erreurs chez les autres, c’est toujours plus facile :-).

Alors ? qu’est-ce que je ferais autrement ? quels points d’attention principaux j’ai retenu ?

Equipe :

J’ai été très rigide à maintes reprises avec David : j’aurai pu par exemple imprimer le document ou le convertir en fichier PDF, plus d’excuse dans ces cas .. c’est tout bête mais ça aurait peut-être fait une différence notable. Bien entendu, un projet mieux maîtrisé aurait généré moins de stress chez lui également ..

Proposition commerciale :

J’aurai éclairci le contenu, découvrir ce qu’il faut faire à la réunion de lancement c’est risqué comme pari surtout avec un engagement de résultat ..

J’aurai remis en cause le choix de la technologie également, je le décris peu dans le récit mais David ne connaissait pas bien la technologie et de nombreux problèmes (version + compatibilité) sont apparus au moment de l’intégration dans l’infrastructure du client.

J’aurai ajouté quelques pré-requis pour le client, histoire qu’il y ait une réflexion plus poussée côté client avant de démarrer et que le client soit conscient de la nécessité de fournir des informations (jeux de test, scénarios de recette, …) à des moments-clés.

Projet :

Plus JAMAIS un fichier Excel ou des échanges de mails pour suivre et recetter un projet. L’Homme a inventé le gestionnaire d’anomalies, le « bugtracker », pour suivre les retours de clients, ce n’est pas pour rien.

Un dernier conseil pour la route

Mais si je devais donner un conseil au Jean-Philippe de cette époque, je lui dirais de ne pas hésiter à suspendre le projet rapidement si le passage d’une étape n’est pas respecté. Cela peut-être profitable à tout le monde. Et ce n’est pas la fin du monde !

Et ça m’est arrivé sur le projet suivant, dès la réunion de lancement ! mais c’est une autre histoire …

 

Est-ce que cette étude de cas vous a intéressé ? Laissez-moi un commentaire ci-dessous pour me donner vos impressions.

Cet article a été posté dans Gestion de projet.

43 réponses à Comment j’ai planté mon premier projet et ce que je ferais autrement

  1. Pingback: Chef de projet malin - Any Ideas | Evénement inter-blogueurs : le conseil que je donnerais au chef de projet que j’étais

  2. Pingback: → "Bref ... mon développeur se fout de ma gueule !" &#9733 Any Ideas

  3. Pingback: → Retour d'expérience avec un saboteur - Vincent Drecq ★ Any Ideas

  4. Pingback: La gestion de projet Waterfall vs Scrum - Nutcache

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Pour vérifier que vous allez mettre un commentaire humainement intelligent : * Time limit is exhausted. Please reload CAPTCHA.