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.

43 réflexions au sujet de “Comment j’ai planté mon premier projet et ce que je ferais autrement”

  1. Bonjour,

    Votre billet est intéressant et enrichissant car peu de gens osent parler de leurs difficultés, de leurs erreurs ou tout simplement de l’échec. Votre première expérience n’est pas bien différente de la mienne. On a coeur de réussir, de faire bien, de faire plaisir sans remettre en question des pratiques ou des situations.

    Vos conclusions sont également très intéressantes et sont ce qu’on appelle communément des leçons apprises.

    Toutefois, j’aimerais vous faire part de mes réflexions sur la gestion des projets au forfait.

    1 J’inclus toujours une phase de cadrage dans mes propositions commerciales notamment pour définir le périmètre du projet et surtout définir ce qui n’en fait pas partie. Ce cadrage fait l’objet d’un livrable validé par le client.

    2 Je ne partage pas totalement votre conclusion concernant le choix de la technologie. Effectivement, vous auriez pu changer de technologie mais est ce que cela aurait répondu aux besoins du client et permis de réaliser l’application ? Une solution aurait été de former David sur cette technologie ou de demander une ressource supplémentaire (cher au départ mais qui aurait pu être rentabilisé par la suite 22 jours de projet au lieu de 50).

    3 Il aurait été peut être intéressant de piloter ce projet avec les méthodes agiles et pour répondre trois problématiques :
    Le périmètre flottant du projet et un besoin en constante évolution
    Un développeur qui attend les spécifications (il faut savoir que l’attente constitue un gaspillage d’après les experts en amélioration continue et en Lean)
    la priorisation des fonctionnalités essentielles et un pilotage de projet par la valeur et par les itérations

    J’espère que mes commentaires vous donneront envie d’échanger un peu plus sur la gestion de projet.

    Cordialement,
    Sébastien Debrauwere

    Répondre
    • Bonjour Sébastien,

      merci pour votre message.

      La technologie n’était pas déterminante d’un point de vue technique, il y avait plusieurs alternatives plus ou moins pertinentes. C’était, je pense avant tout un choix par goût / envie qu’un choix stratégique pour le projet.

      Je reste dubitatif sur le fait d’envoyer quelqu’un se faire former quelques jours pour qu’il soit opérationnel dans la foulée pour un projet. De ce que j’ai pu voir et tester, c’est rentable à partir d’une certaine taille de projet et / ou d’équipe notamment si quelqu’un de plus expérimenté peut également coacher le débutant.

      Mais cela demande du coup du budget formation (qui peut-être difficile à débloquer) ou d’avoir une ressource expérimentée qui n’existe parfois tout simplement pas .. Dans beaucoup de contextes, on fait avec les personnes présentes, formées ou non ..

      Pour un projet de 22 jours, je pense qu’il aurait mieux fallu partir sur une technologie déjà maîtrisée sans quoi la courbe d’apprentissage va plomber rapidement l’avancement.

      Je vous rejoins complètement sur la méthode agile et je pense que l’expérience m’a convaincu de cette démarche. Je reste toutefois sceptique sur la compatibilité forfait / agile sur de nouveaux projets. Une fois qu’il y a un minimum de confiance entre le client et l’équipe et qu’un rythme de croisière est atteint, je peux le concevoir facilement. Mais pour un projet nouveau, dans un contexte nouveau, je serai curieux d’écouter des retours d’expérience.

      A bientôt,
      Jean-Philippe

      Répondre
      • Bonjour,

        Je rejoins entièrement Sébastien Debrauwere sur le fait de former quelqu’un et ce même sur ce genre de projet.

        Une formation de 5 jours sur un projet comme le votre de 44j/h (2 personnes X 22j) ne représente que 5 à 7% du tarif de facturation pour la partie RH.
        Ce qui permet:
        – d’acquérir une nouvelle connaissance
        – d’acquérir une nouvelle compétence en pratiquant sur un projet
        – Valoriser cette compétence pour l’acquisition de nouveaux marchés (un des avantages pour l’entreprise)
        – Impliquer et valoriser la personne qui suivra la formation
        Comme la personne était en intercontrat, l’absence (physique et en terme de couts) ne posait aucun problème.

        Je vais passer tous les avantages indéniables pour l’entreprise de faire monter en compétence ses RH.
        Sur un périmètre plus restreint, pour un manager (sur projet ou d’un service comme ça a été mon cas), la formation reste à mon sens un des outils les plus puissant de management.

        La rentabilité, sur ce dispositif, ne se mesure pas seulement à court terme et pas seulement en terme financier.

        Ensuite, savoir sur ce type de projet quelle techno était la plus adaptée est un point sur lequel je ne peux me prononcer.
        Pour un go/no go, il aurait fallut une étude en gestion de sur ce point et voir ce qu’apporterai, au delà du projet, l’acquisition d’une nouvelle compétence risque (un SWOT aurait du être réalisé en plus par la direction de projet).

        Mais dire que la courbe d’apprentissage aurait plombé le projet est un faux problème. Mieux vaut acquérir des compétences sur de petits projets que sur de gros projets stratégiques.
        L’environnement étant plus simple (ça n’a pas été le cas ici mais par simple manque de connaissance en techniques de gestion de projet… on est tous passé par là), tout dérapage peut être très vite maitrisé.
        L’exception étant « l’harponnage » d’un gros client, pour entrer dans sa short-list fournisseur. Mais dans ce cas là on ne met que des seniors sur le projet.

        Cordialement
        A.K. de http://www.exam-pm.com

        Répondre
        • Bonjour « exampm » 😉

          je suis tout à fait d’accord que former est une priorité d’un point de vue management et j’étais le premier à « râler » que le budget formation était trop faible quand j’étais responsable d’un centre de compétences. Je ne remets pas en question la formation de manière générale, je ne pense pas avoir écrit cela, sinon c’est une erreur.

          Je me trompe peut-être mais mon argument pour ce contexte est le suivant : pour un projet de 22 jours de charges, former quelqu’un quelques jours n’aurait pas suffi pour réussir le projet. Se former à un langage de programmation ou à un framework a une courbe d’apprentissage incompatible avec un délai aussi court.

          C’est pourquoi j’aurais préconisé une technologie mieux maîtrisée ou plus répandue (mais aussi bien j’aurais pu me retrouver avec une ressource ne connaissant pas cette technologie …). Et puis il y a la formation et la vraie vie, c’est étrange comme les exercices de formation marchent toujours bien :-).

          Bien sûr, avec le recul, quand on y passe 99 jours de charges au final, moi aussi je me dis qu’il aurait mieux fallu former David, mais c’est toujours facile après coup, n’est-ce pas ? et puis cela dépend du budget de formation, de la disponibilité d’une formation aux dates souhaitées, etc. Si vous pouviez déclencher une formation comme bon vous semble, je vous envie !

          Merci pour ce commentaire, j’espère qu’au détour d’un futur commentaire j’aurais enfin la chance de connaître votre prénom ! 😉

          Jean-Philippe

          Répondre
  2. Bonjour,

    Rassurez moi ceci c’est produit il y a bien longtemps?

    Que celui qui n’a pas connu une telle situation nous écrive!

    La recommandation que j’ajouterais est: s’assurer que le client est ou travaille avec un praticien du métier qui utilisera la nouvelle application. Dans la très grande majorité des cas un projet n’est que l’évolution d’un système existant. Nous pouvons définir le service minimum du projet: la reprise des fonctionnalités déjà opérationnelles.
    Cette première étape permet de quantifier un coût minimum qui peut d’ailleurs aboutir rapidement à votre dernière recommandation:
    « ne pas hésiter à suspendre le projet »
    car
    « Et ce n’est pas la fin du monde ! »
    Merci pour votre témoignage.

    A demain!
    Jean-Louis Verdot

    Répondre
    • Bonjour Jean-Louis,

      Des dizaines de projets sont passés ensuite oui ! 🙂
      Je partage votre avis, plus proche le projet est de l’utilisateur final, meilleures sont les chances de réussite.

      Jean-Philippe

      Répondre
  3. Bravo pour avoir (osé écrire) écrit cette expérience.
    on est tous passé plus ou moins par là.
    personnellement, j’ai eu la chance d’avoir un client expérimenté, professionnel et surtout honnête lors de mes premiers projets ainsi qu’un soutien de mon management (point régulier de suivi – ce qui a apparemment manqué dans l’expérience ici) et cela m’a permis de réussir mes premiers projets.
    Je vous avoue que j’ai déjà transféré certains projets (3 en l’occurrence) vers des collègues car la relation lors de la définition du ‘scope’ entre le client et moi ne se passait pas de la meilleure manière (*). Une des clés de la réussite d’un projet réside dans la bonne collaboration et l’entente réciproque entre le chef de projet et le représentant du client.
    Cordialement,
    Paul
    (*) un des 3 projets a été abandonné par mon remplaçant, le second a été mené à bon port par mon remplaçant qui était pourtant « junior », le troisième projet, on m’a demandé de revenir m’en occuper, j’ai accepté après avoir pu exiger une autre attitude de la part du représentant du client et le projet s’est bien déroulé.

    Répondre
    • Vous abordez un point très juste, parfois ça ne passe tout simplement pas entre le client. J’ai repris une fois un projet d’une dizaine de jours suite au départ de mon prédécesseur et le client m’a quand même raccroché 3 fois au nez sur les 2 premiers jours ! 🙂 Tout ça parce que je lui demandais de me donner des détails sur ce qui ne marchait pas ! Le commercial s’en sortait beaucoup mieux, c’est donc lui qui gérait le contact au quotidien et moi qui gérais l’équipe.

      Et vous avez raison, changer le chef de projet peut résoudre « l’affaire ». Ca demande de l’humilité de transférer ses projets et du recul pour se rendre compte que ce n’est pas un échec. Mais c’est parfois profitable à tout le monde.

      Merci pour ce commentaire, Paul.

      Répondre
    • Bonjour,

      Merci pour cette analyse intéressante. J’ai moi-même eu des difficultés en tant que consultante en AMOA sur 2 sur projets avec le client. Cela m’a beaucoup désarçonnée et fait perdre confiance en moi. Mais, j’ai compris 2 choses : 1 – que l’on ne peut pas plaire à tout le monde (c’est évident, mais ca fait pas toujours du bien) et 2 – il faut à la fois de la souplesse et en même temps, de l’assurance dans ce sur quoi on croit : dans son projet, sinon, ca ne passe jamais avec les clients !
      Au plaisir de lire encore ce type de nouveaux billets !
      Bonne année !
      FLCC

      Répondre
  4. Le directeur de projets a tendance à forcer ses chefs de projets à occuper les inter-contrats.
    A cause de cette pression et aussi afin d’éviter une trop grosse dérive par rapport au planning, le chef de projet met en place une stratégie afin de démarrer les phases de conception et de développement avant même que la spécification ne soit validée.
    Ainsi on sort la carte du prototype: le développement devient un prototype qui s’améliorera (au fur et à mesure que la spécification avancera) et deviendra à terme le logiciel définitif.
    Nous l’avons tous fait, si l’idée parait bonne mais elle a tendance à générer de nouveaux besoins, non pardon, elle a tendance à générer une clarification du besoin initial… En fait, ca permet à l’utilisateur d’affiner son besoin et de demander toujours plus…
    Dire stop au client est difficile, le chef de projet se doit d’être conciliant, surtout si c’est un nouveau client (il ne faudrait pas se fermer la porte à de futurs projets…). Je pense qu’il vaut mieux dire STOP plutôt que de continuer et au final avoir un logiciel qui ne répondra pas aux attentes du client.
    Merci pour votre témoignage et pour vos billets qui sont d’une grande qualité.

    Répondre
  5. S’il fallait encore des preuves pour montrer qu’on ne construit pas une application web, comme on construit une maison, du coup merci pour ce témoignage.

    Ce genre de méthodologie a essayer de tout chiffrer et prévoir à l’avance n’est vraiment pas destinée à nos métiers dans le web.

    Répondre
  6. Bonjour,

    Histoire intéressante. Comme Sébastien, je commence toujours le projet par une phase de cadrage. J’ai été prestataire, j’achète aujourd’hui des prestations, cela ne change rien. Le cahier des charges est en général un peu flou pour laisser libre court « à l’imagination » du prestataire. La phase de cadrage est la pour préciser les choses. A partir du moment où un client fait évoluer sans cesse le périmètre c’est aussi qu’il y a un problème de son côté. On ne fait pas un marché pour 22 jours de prestations mais terminer avec 5 fois plus à la fin, et un produit non fonctionnel, est un peu aberrant. Concernant votre développeur, j’en ai eu aussi dans le même style. Le fait de ne pas vouloir lire une spécification par ce que fournie par le logiciel X est une preuve de sa souplesse, de son ouverture et de son adaptabilité. Ne maîtrisant pas une technologie, c’est aussi une façon de masquer ses manques. A propos de la gestion des anomalies avec un tableur … Vous oubliez qu’un logiciel de « bug racking » nécessite lui aussi une phase d’apprentissage et, pour un projet de 33 jours, est-ce indispensable ? J’ai utilisé un tableur pour des projets de plusieurs milliers de jours sans que cela ne pose de problème particulier. Il était bien maîtrisé par tous et ne nécessite pas d’usine à gaz complémentaire. Juste un dernier mot. Un client, c’est comme un fournisseur : ça s’éduque. Quelle part de responsabilité a-t-il assumé dans ce projet, le périmètre évoluant sans cesse. N’oubliez pas : si le titre du projet est abscons ….

    Répondre
    • Bonjour MVT (?),

      Je vous rejoins sur le fait q’un client ça s’éduque tout comme une équipe, tout comme un fournisseur. Cela prend juste du temps que l’on n’a parfois pas.

      Quand je parle d’un logiciel de bugtracking pour ce projet, j’entends quelque chose de simple pour le client : Sujet + Description + pièce jointe. Ce qui, en terme d’utilisabilité revient à envoyer un email. Ensuite, l’ajout de commentaires et la mise à jour de statut permet un premier niveau de suivi efficace.

      Je veux bien croire que vous ayez utilisé avec succès un tableur pour des projets de milliers de jours mais j’ai des doutes malgré tout sur le fait que cela reste une solution des plus efficaces.

      Par ailleurs, désormais je précise dès la phase d’avant vente pour les projets à engagement de résultats qu’un des pré-requis est d’utiliser l’outil de bugtracking que nous proposons car c’est en partie parce que nous utilisons ce produit que nous pouvons nous engager.

      Jean-Philippe

      Répondre
  7. Merci pour ce témoignage, pour moi il y a un acteur qui aurait pu faire mieux, c’est le directeur de projet dont le rôle ne doit pas être juste de relever les compteurs… mais surtout de sentir si le projet part dans le mur ou pas.
    Vu ce que vous en racontez, ce n’était pas très difficile à voir avec un peu d’expérience.

    Concernant les spécifications, il suffit parfois de choses très bêtes pour partir en erreur, j’ai vu un projet pour lequel le Chef de Projet imprimait les spécifications pour les développeurs. Elles n’étaient pas agrafées, et il n’y avait pas de pied de pages (version, date, n° de page). Un coup de vent et le projet a pris plusieurs jours de retard (mauvaise version, mélange des fonctionnalités) !

    Répondre
    • Je ne blâme par le directeur de projets car il devait faire face à un contexte difficile de reprise de contextes multiples et un projet de 22 jours n’était pas forcément sa priorité immédiate ..

      Répondre
  8. Je trouve ce type de billet très enrichissant et c’est exactement l’objet de mon projet actuel: favoriser les retours d’expériences (positives ou négatives) afin de corriger les « imperfections ». Merci beaucoup de ce partage, cela me donne une idée de ce que pourrait être ma ligne éditoriale

    Répondre
  9. Bonjour

    Excellent article.
    Je suis développeur depuis 12 ans, tout ce que tu dis, j’ai l’impression de le connaitre par coeur.
    Je ne suis jamais passé chef de projet, mais si jamais c’est le cas un jour, je suis sur que je ferais les
    mêmes erreurs que toi ! Et pourtant je connais tout ce que tu dis. Les difficultés de négociations avec le Client.
    Je tenais à te dire que tes chefs ont été affreux avec toi. Confier un projet informatique à un chef de projet débutant sans lui donner plus de méthodologie, c’est au mieux faire preuve de naiveté,
    au pire du masochisme. Il n’y a qu’en France que l’on pense qu’il suffit de bonne volonté et des heures de travail pour être chef.
    Plusieurs choses ne collent pas : Le n+2 qui est un copain du client.
    L’estimation de 50 jours qui est faite par quelqu’un qui ne réalise pas le projet. (probablement un commercial ou le client lui-même)
    Les fonctionnalités qui évoluent en cours de développement.
    Le fait qu’on te propulse chef sans que tu l’ai demandé !

    Je te recommande vivement la méthodologie scrum dont tu as du entrendre parler ! Cela a changé ma vie de développeur. Je travaille beaucoup moins stressé ! J’ai l’impression d’avancer, et le chef de projet n’attends pas plus de moi que ce que l’on a définit ! Tu trouveras des formations scrum à passer en utilisant ton DIF. Ca vaut le coup !

    Je trouve que tu as beaucoup d’applombs. Je me serais sans doute éffondré, remis en cause eternellement sur ce projet. Même si je me doute que cela t’as affecté, tu es très lucide, et tu as été capable d’écrire un article avec du recul. Je serais envahi de colère et de ressentiments à ta place : Bravo. Je pense que tu feras un bon chef de projet avec cet état d’esprit.

    Cordialement,
    Cédric

    Répondre
    • Bonjour Cédric,

      merci pour ton message. L’idée de ce genre d’article est justement de permettre à certaines personnes d’éviter de faire les mêmes erreurs.

      Je n’ai eu l’occasion de pratiquer des méthodes agiles qu’en interne, de rares fois avec un client externe, je suis effectivement convaincu de l’approche mais je reste dubitatif sur une compatibilité avec le mode forfait.

      Ce projet date de 2006 et il a posé les bases de ce qui allait être mon expérience de chef de projet. C’est paradoxal à dire mais je ne le regrette pas au final !

      Jean-Philippe

      Répondre
  10. Bonjour,

    Je suis Directeur de projet depuis plus de 20 ans et je ne vois pas dans tes conclusions ce qui me semble être la base de tout : Comment peut on avoir un chiffrage convenu avec le client alors que le besoin est visiblement loin d’être clair ?

    Petit conseil : Il aurait mieux fallu vendre une assistance au client pour formaliser son besoin puis lui faire une proposition au forfait.

    Cordialement
    Denis

    Répondre
    • Bonjour Denis,

      merci pour ton message. La clarté d’un besoin est très relative, si l’on veut comprendre ce que veut le client, si on veut chiffrer, si on veut spécifier, … le contexte, les compétences et l’expérience de chacun peut faire que parfois ça ne se passe pas aussi bien que l’on souhaiterait.

      Merci pour le petit conseil, c’est toujours plus simple avec un peu d’expérience en plus, n’est-ce pas ? 😉 … en revanche, le client n’est pas toujours prêt à payer de l’assistance s’il pense que son besoin est suffisamment clair et pour peu que la concurrence fasse directement une proposition au forfait, les chances de remporter l’appel d’offre diminuent (même si c’est parfois pas plus mal de ne pas gagner ..).

      Jean-Philippe

      Répondre
      • JP

        Tout ce que tu dis est classique malheureusement et je peux te garantir que nous vivons la même chose.
        Les années passées mon appris, que contrairement à ce que je pouvais croire quand j’étais jeune et fougeux (et oui les années passent), il vaut mieux parfois perdre une affaire que la gagner n’importe comment.
        Si toutefois ta Direction veut absolument « rentrer » chez ce client alors il faut qu’elle le fasse en connaissance de cause et la responsabilité du Chef de projet est alors de sortir une évaluation en jours (certes macro) du risque pour que la Direction prenne sa décision en connaissance de cause et que le chef de projet qui héritera de la patate chaude soit couvert.
        Concrètement sur des dossiers de plusieurs M€, il m’est déjà arrivé d’annoncer un risque de 500K€ à ma Direction parce certains paramètres me semblaient flous ou non vus par le client.

        A ta dispo pour continuer d’échanger si tu le souhaites.

        Denis

        Répondre
        • Ta direction a / avait une approche du risque très mature vraisemblablement. Je me rappelle avoir fait des analyses de risques avec parfois un no-go ferme, et cela finissait souvent aux oubliettes .. et c’est le chef de projet qui prenait ensuite ..

          Par défaut, de toute façon, lorsqu’on reprend un projet, je pense qu’une nouvelle analyse de la situation est indispensable pour pouvoir se couvrir un minimum.

          JP

          Répondre
  11. Bonjour 🙂

    J’ai lu tous les commentaires et je les trouve très enrichissants.

    Je suis une élève au maîtrise en soins infirmières et j’aimerais vous demander si vous connaissez quelqu’un qui peut jeter un coup d’oeil dans mon projet. C’est un projet très simple.

    De plus, je sais que le but de cette discussion c’est l’autre.

    Désolé de poser ce genre de commentaire…mais j’ai voulu essayer, car j’ai besoin d’une opinion d’une personne qui travaille avec gestion de projet.

    D’avance, merci beaucoup.

    Lucinei Sachetti

    Répondre
    • Bonjour Lucinei,

      merci pour votre commentaire. De quel type de projet s’agit-il ? et vous auriez besoin d’une opinion sur quels aspects en particulier ?

      JP

      Répondre
  12. Bonjour Jean-Philippe,
    Merci pour cet article.

    Ton exemple ressemble étrangement au mien, avec le même client, mais là, le projet n’a pas non plus été stoppé !

    Est ce que ça se fait de stopper uni projet ? Apparemment OUI !

    Difficile à croire d’après cette phrase : « Le client est ROI »

    Alexandre

    Répondre
  13. Merci pour cet article qui m’intéresse beaucoup car j’aimerais moi aussi être chef de projet et précisément chef de projet web! Actuellement je suis autodidacte en web marketing depuis un peux plus d’un an et j’ai commencé tout récemment a accompagner certaines personnes dans la réalisation de leurs projets en rapport avec le web marketing. Mais je voudrais formaliser mes compétences par une formation certifiante qui me donnerais véritablement la compétence de chef de projet web et j’avoue que ton aide me serait d’une grande utilité car jusqu’ici j’ai rien sous la main!

    Merci d’avance

    Répondre
    • avant tout, une formation certifiante, une certification, permet d’être reconnu sur un marché de l’emploi, c’est une sorte de tampon qui valide un ensemble de connaissances et en second plan, parfois, d’expérience. Cet avis n’engage que moi mais il faut être au clair avec vos objectifs.

      Cela étant dit, comment pourrais-je vous aider ? 🙂

      Répondre
        • Tout dépend de l’objectif que vous visez donc :

          – augmenter votre attractivité sur le marché du travail et/ou apprendre une méthodologie reconnue : la certification semble de mise. Selon votre contexte, vous avez le choix : Prince2, PMP, ou autre

          – améliorer vos connaissances dans la technique de gestion de projet : vous avez un ensemble d’ouvrages qui permettent de le faire et qui recouvrent généralement un tronc commun de connaissances (Pert, Gantt, méthodes d’estimation, …)

          – renforcer votre compétence de chef de projet : je parle ici du rôle de chef de projet avant la compétence en gestion de projet, il faut alors s’orienter vers une approche comme celle que je propose dans le programme Expérience et Equilibre Projet : https://www.anyideas.net/2012/11/devenir-chef-de-projet-programme-2ep/

          Cette dernière permet de gagner en expérience car elle aborde les pièges et les erreurs les plus courants des chefs de projets.

          Cela vous aide-t-il ?
          JP

          Répondre
  14. Merci pour ce témoignage
    Moi même je viens de vivre mon premier projet en tant que CP en mode chiffrage serré , développeurs débutants, techno gratuite et non maîtrisée
    La chance que j’ai eu c’est que la propal était déjà faite et avec des notions de SFDs à valider avant développement, mm si dans les faits ça n’a pas été le cas pour tous les sprints, avec demande de cahier de recette de la part du client….
    Et puis l’équipe de dev était très impliquée et le DP suivait tout cela de très près et le client, malgré un CP aussi incompétent que con, était somme toute raisonnable, on voulait tous que ça marche au final.

    Je crois que si j’avais été à ta place ça aurait explosé en plein vol ou alors c’est moi.

    je vais suivre tes liens, certainement très instructifs.

    bonne continuation !

    Répondre
    • Merci Greg pour ce retour ! on réagit tous différemment et peut-être que j’aurai dû « exploser » en plein vol comme tu dis, en tapant du poing sur la table ou en disant « Stop c’est trop pour moi » plutôt que d’encaisser et finir 2 jours cloués au lit .. mais c’était demander trop de recul pour moi pour l’époque je pense. Maintenant j’ai beaucoup moins de scrupules à dire que les choses ne vont pas 🙂

      Excellente continuation à toi,
      JP

      Répondre
  15. Je crois, que pour faire de la bonne direction de projet, il faut oublier son coté humain (on va s’arranger, oui, on peut en faire plus, oui, je comprends…) et se recentrer sur l’objectif final, tout le temps. Le cadre est ainsi plus clair pour tout le monde : pour soi et le partenaire / client ou autre. Mais c’est tout un apprentissage.
    Je travaille en collectivité. Les élus me confient une mission. Je pose avec eux les objectifs, puis je détaille la méthodologie et le calendrier. Même s’ils valident ces éléments, ils veulent toujours, à un moment, modifier le contenu de la mission ou un des éléments fondateurs qui la compose. Si je peux le faire rapidement, je le fais (ça prend plus de temps, de budget…) mais souvent, ça bouscule trop de choses, du coup, le projet n’avance pas. Là, soit on arrête, soit c’est un développement de la mission qui aura lieu plus tard.
    les gens confondent souvent « idée » et « projet ». Ce dernier demandant une vraie structuration…
    Comme disait l’autre, c’est en forgeant….
    Bonne continuation

    Répondre
  16. Bonjour à tous et merci beaucoup pour ces retours d’expériences.
    Une problématique qui se pose lorsque l’on répond à un appel d’offre c’est que le client s’attend le plus souvent à avoir :
    – en un Temps fixe
    – à un Prix (ou coût/ressources) fixe
    – avec une Qualité fixe
    – un Périmètre (projet ou produit) fixe

    La théorie qui nous a été exposée lors d’un événement IIBA par François Bachmann, spécialiste en Agilité, est qu’il est impossible que c’est 4 variables soient fixes.

    Dans l’approche classique, dite waterfall :
    – le Périmètre et la Qualité sont des variables fixées
    – le Prix (ou coût/ressources) et le Temps sont des variables estimées (prédictions) (et le plus souvent l’ensemble du risque est assumé par le fournisseur de services)

    Dans l’approche Agile :
    – le Temps, le Prix (ou coût/ressources), et la Qualité sont des variables fixées
    – le Périmètre est une variable estimée (prédiction)

    La question qui se pose est : « comment le périmètre ne serait pas fixe alors qu’il faut le contractualiser! »
    Il s’agit de convaincre le client d’adopter une « win-win strategy » basée sur :
    – la confiance mutuelle,
    – et l’évaluation en continu du ROI (ou valeur ajoutée relative) de chaque tâche à réaliser
    Ainsi, si la planification est importante, le plan n’est pas un livrable mais un outil, (au moment où il est réalisé, il n’est déjà plus d’actualité) un minimum de temps doit donc lui être consacré.
    De même, il semble qu’à chaque fois que l’on se rend compte qu’une tâche prend plus de temps que prévu, il faut s’interroger sur son ROI et l’intérêt de continuer ou de passer à autre chose, ceci idéalement en transparence avec le client (win-win).
    Si une tâche n’a pas pu être réalisée dans le « Time box », avec les ressources et la qualité fixée, il faut faire une rétrospective et identifier les points d’amélioration pour les prochaines itérations.

    Un type de contrat qui m’a semblé très interessant est le « Money For Nothing, Change For Free » :
    (désolé, pas trop le temps de traduire)
    « Definition: We mutually agree on working together, and thereby build trust in each others expertise.

    Customer Participation in Scrum Team:
    The Customer is expected to be active in the project. The role of the Customer includes the following:
    1. Prioritize features by business value and have them implemented in order of maximum value (or ROI)
    2. Mutually agreed estimates for all work items. The official representatives of both parties need to agree. This needs to be noted in a signed addendum to the contract for each change.
    3. Participate in each Sprint planning meeting by discussing the selected features with Company team, including answering questions to provide clarification to the team.
    4. Participate in writing the conditions of satisfaction for each feature, so the team and client have a shared definition of when a feature is done. These conditions should be completed as part of a user story before any code is written.
    5. Participate in each Sprint review meeting, and provide timely feedback both for both work-in-progress and completed work.

    ***To company: Things to ensure are defined in the contract:
    – Total value of the contract
    – Rates for time and materials billing
    – Scope of the contract

    Clause: Early Termination (Money for Nothing)
    The Customer may terminate the contract at the end of any Sprint. The standard metric for termination is when the Customer perceives the cost of continuing the project is higher than the additional value received. The Customer will pay Company 20% of the remaining contract value to exercise early termination.
    Company commits to delivering 80% of the project scope as high quality by the agreed upon delivery date. High quality is defined by the agreed upon Definition of Done.
    This clause can only be enacted if the Customer maintains Participation in the Team Scrum during the project.
    In the event that both parties cannot mutually agree on work item estimates or that the Customer does not maintain participation in the Scrum Team, the contract shall revert to a time and materials billing.

    Clause: Change For Free
    If the Customer maintains Participation in Scrum Team during the entire project, Customer shall be able to make changes to the Scope without incurring any additional cost if total Scope of contracted work is not changed. New features may be added for free at Sprint boundaries if items of equal scope are removed from the contract. »

    A nous de faire prendre conscience à tous les acteurs que la stratégie « Gagnant-Gagnant » est la meilleure.

    Fouad

    Répondre
    • Merci Fouad pour ce commentaire.

      Je ne suis pas un expert de la méthode Scrum et des méthodes agiles en général. Je suis convaincu que le modèle Waterfall – Cycle en V a ses limites sur une majorité de projets notamment informatique et qu’une démarche Agile serait certainement plus appropriée.

      Mais voici quelques remarques en vrac :

      – Convaincre le client de démarrer sur une confiance mutuelle : « on ne se connaît mais faites-moi confiance, ça va bien se passer ! » fait penser à un discours de mauvais commercial ;-). Je comprends ce que vous dites, bien entendu, mais la confiance ça se construit, ça ne se décrête pas. Parce qu’elle va être mise à l’épreuve très rapidement, il va falloir qu’elle soit solide ..

      – Vérifier le ROI de chaque fonctionnalité, sur le principe, je suis tout à fait d’accord. En pratique, c’est plus compliqué. Parfois rien que le projet a un ROI flou. S’il s’agit de mettre en place de nouvelles réglementations, peu importe le ROI, faut le faire, faut le faire sinon c’est être hors la loi .. Faire le calcul du ROI au niveau fonctionnalité, et prioriser pourquoi pas ..

      – Pour moi, la qualité peut être variable : le client demande à faire Paris-Lyon en 1ère classe. S’il n’a pas le budget, ou que ce n’est pas possible, on peut diminuer la qualité et faire le trajet en 2ème classe. L’objectif est atteint mais avec un confort moindre. Bien sûr tout dépend de ce qu’on entend par qualité et périmètre, certaines choses peuvent faire des va et vient selon les personnes et les interprétations …

      D’expérience les projets agiles où ça se passe bien, c’est quand tout le monde fait preuve de pragmatisme (et pour certaines c’est peine perdue), qu’on avance rapidement mais un pas l’un après l’autre, fonctionnalité après fonctionnalité, et qu’il n’y a pas 40 personnes pour discuter d’une fonctionnalité ..

      Il y aurait beaucoup à dire …

      Merci pour cette contribution !

      Répondre
  17. C est toujour pareil le dev tjr de l arnaque . La seule methode qui marcherai serai de faire signer dans les conditions de vente que le prestataore s engage a coder un produit selon les specs du client et tan pis si a la fin le client estimer que il manque des choses qie il n avait pas specifie clairement bref ce domaine est trop complexe pour le traiter comme un autre corps de metier

    Répondre
  18. Merci pour le partage de cette expérience ! en tous cas fallait bien que ça arrive un jour ou un autre et dans tous les domaines , c’est juste inévitable , il faut que ça arrive une fois pour mieux comprendre par la suite ^^

    Répondre

Laisser un commentaire