Retour d’expérience projet : engagement et agilité – 2/3

Retour d’expérience projet : engagement et agilité – 2/3

Je vous racontais dans l’article précédent comment s’était passée la phase d’avant-vente sur le projet : un client qui veut avoir la souplesse du mode régie ET l’engagement du forfait, un consultant « créatif » idéal pour un projet en régie mais un cauchemard à gérer sur un projet au forfait et une demande du client d’avoir le consultant en face de lui pour bosser.

C’est sans compter que Julien vient de finir quelques projets chez ce même client, au sein des mêmes équipes ou presque, et qu’il risque de devoir intervenir sur ces derniers pour corriger « deux trois » dernières choses, ce qui est courant mais n’arrange pas mes affaires.

Allez hop, on y va, en route pour l’aventure !

Je briefe donc Julien sur le démarrage du projet, je planifie un point tous les deux jours par téléphone avec lui et je lui demande de me remonter une alerte s’il doit intervenir sur un autre projet ou si le client lui fait des demandes en direct.

En effet, même si je suis à distance, je veux rester le point d’entrée, s’il y a des demandes de changement de périmètre par exemple. C’est un peu contraignant mais sinon je suis cuit !

La réunion de lancement a lieu, j’insiste donc sur le mode de communication qui passe principalement par moi pour les questions projets, pour les aspects purement techniques (mot de passe d’accès, localisation des fichiers, etc.) il peut traiter bien sûr en direct avec Julien. Je clarifie la limite le plus possible.

Le client est d’accord.

C’est donc dit à l’oral et tracé dans le compte rendu.

Un autre point qui peut poser problème ensuite, un pré-requis technique que doit fournir le client car la réalisation va s’appuyer sur ce pré-requis. C’est comme si le client devait fournir le pot de peinture car il fait son propre mélange. Sans ce pot de peinture, je ne vais pas pouvoir commencer à peindre.

Ce que je crains, c’est que le pot de peinture ne soit pas prêt en temps et en heure, donc je demande au client de s’engager à ce que le pot de peinture soit prêt à une date précise et je lui indique bien que je considère cela comme un risque et que nous devons être vigilants tous les deux.

Ce que je veux aussi éviter, c’est qu’en cours de réalisation, le client décide que la couleur ne lui convient finalement pas et décide de la modifier « très légèrement », ce qui nous obligerait à refaire une couche pour voir si la couleur du mur est bien homogène, voire il faudrait peut-être repeindre tout le mur.

Donc j’insiste sur le fait qu’une fois le pot de peinture livré, c’est figé, plus personne ne bouge, on ne change plus rien, sinon l’impact sera à la charge du client.

Le client fait la moue mais il est d’accord.

C’est donc dit à l’oral et tracé dans le compte rendu.

Dans la voiture, sur le chemin du retour sur les quais de Seine, Nico joue à Taxi 18 et pile pour ne pas griller un feu rouge.

Une fois arrêté, il me fait un retour : « Dis donc, c’était un peu ceinture, bretelles et parapluie sur les pré-requis, tu crois pas ? »

Je décrispe la main de la poignée au-dessus de la vitre et je lui réponds : « Comme ça au moins, il ne pourra pas dire que je ne l’avais pas prévenu, c’est dans son intérêt autant que dans le mien. »

Julien, lui, est resté chez le client et a démarré le projet ..

Il pleut, il pleut, bergère …

Il s’agit de rédiger les spécifications pour bien définir ce qui va être réalisé ensuite.

Le projet avance. Le client a des demandes particulières, un outil de documentation interne à compléter et une fonctionnalité qui évolue par rapport à ce qui était prévu initialement.

« Rien de bien méchant », me dit Julien, « ça reste dans la charge prévue. »

« Mouuuais », lui dis-je au téléphone. « Attention, toi aussi tu t’engages, si ça ne rentre pas dans la charge prévue tu me le dis. Mais si tu me dis que ça rentre dans l’estimation, tu t’engages à le faire dans l’estimation, ok ? ».

« Euh oui oui ça va le faire .. », me dit-il moyennement convaincant.

Une première version des spécifications est rédigée et envoyée au client. Il y a des questions en suspens au niveau fonctionnel, le client n’a pas tous les scénarios en tête, il doit reboucler avec d’autres personnes en interne mais il souhaite commencer les développements malgré tout pour avoir une première idée du résultat.

Des aménagements sont donc faits dans les spécifications pour parer au manque d’infos pour le moment et pour pouvoir démarrer la réalisation. Je préviens le client qu’on peut être flexible mais qu’il va falloir apporter des réponses rapides sans quoi certaines fonctionnalités passeront hors périmètre.

Le client est d’accord.

C’est donc dit à l’oral et tracé dans le compte rendu.

Mais je commence à me dire que ça ne va pas le faire comme ça tout le projet. D’une part, j’ai l’impression d’avoir 5 % des infos de ce qui se passe, et d’autre part j’ai une forte impression que ça ne suit pas tout à fait les rails que j’ai posés pour le projet …

Il y a également un souci au niveau des cahiers de recette, le client s’attend à ce qu’on les rédige, tandis que dans notre proposition il était question que ce soit lui qui les fournisse.

J’apprends au détour d’un mail qu’une décision est prise sans moi entre le client et Julien, il y aura plusieurs documents pour les cahiers de recette. Et Julien va largement y contribuer.

Donc là je commence à serrer les dents, j’ai l’impression d’avoir le mauvais rôle dans l’histoire et qu’en plus je perds le contrôle du projet.

Mais je ne vais pas lâcher le morceau pour autant.

Je fais un vif rappel des règles à Julien en privé et également une remarque au client en réunion de suivi. Je sais que ce n’est pas facile comme position pour Julien mais je préfère être ferme là-dessus pour éviter qu’il ne passe en mode sous-marin pour le reste du projet.

Je cours ensuite après le Procès Verbal de validation des spécifications. Ca traîne pour des questions de qui peut valider officiellement, c’est un argument classique, donc j’insiste lourdement pour l’obtenir. J’ai déjà démarré la réalisation sur un autre projet sans une validation des spécifications, j’ai vu ce que ça a donné, ce n’était pas beau à voir et moi non plus :-).

Je l’obtiens au bout de quelques jours en fin de compte, je suis donc plus serein pour continuer même s’il reste des points fonctionnels flous à gérer. Je remets un petit coup de pression sur le client pour les points fonctionnels mais je sens bien qu’il n’a pas l’autorité nécessaire pour faire avancer les choses en interne.

Allo Papa Tango Charlie, répondez, nous vous cherchons …

C’est au cours de la 3ème semaine que les choses commencent à se gâter.

Nous sommes à 30 % d’avancement sur le projet. Depuis 3 jours, je n’ai plus de nouvelles de Julien, blackout total, pas de son pas d’image. Le responsable des opérations lui envoie un email pour le recadrer. Encore 24 heures, et je vais devoir débarquer à l’improviste chez le client pour voir ce qu’il se passe, super !

Puis enfin un message sur mon répondeur : « Ouais, non, tout va bien, ça a été hyper busy ces derniers jours, je suis à la bourre sur mes emails, ça avance comme convenu mais je vais devoir intervenir sur les autres projets pour quelques heures. »

Jusque là, j’arrive à aménager du temps pour que Julien puisse intervenir sur ses anciens projets mais ça ampute un peu ma marge en délai et son reporting sur le temps passé montre parfois des incohérences, ça sent un peu la magouille pas bien méchante mais quand même, faudra pas qu’il abuse.

D’un point de vue réalisation, le découpage initial des tâches ne correspond plus à la réalité, le client et Julien ont décidé d’une autre approche technique pour les développements. Ils préfèrent également créer des prototypes d’écrans et repasser dessus pour les finaliser ensuite.

Ca ne m’arrange pas en terme de suivi et je trouve ça difficile à cadrer. Je demande donc à Julien de me refaire le découpage des tâches restantes avec le reste à faire.

Il n’est pas ravi mais je n’ai pas trop le choix si je veux qu’il reste dans le budget.

Le projet suit son cours, nous sommes à 45 % d’avancement, ça bouge un peu sur la documentation et le périmètre : une simplification d’un côté, un ajout d’un autre et Julien finit une autre fonctionnalité un peu en avance.

C’est toujours délicat de montrer qu’on finit une tâche en avance car le client peut demander quelque chose en plus, pensant qu’il y a droit.

Le problème c’est que tant que le projet n’est pas fini, on ne sait pas si on est vraiment en avance ou pas. Cela reste du prévisionnel. D’autant que dans ce sens, le client peut penser avoir droit à du «bonus», mais dans l’autre, en cas de retard, il ne va pas mettre la main à la poche pour compenser, forfait oblige.

On arrive à une phase de pré-recette, que je planifie systématiquement pour éviter d’avoir de mauvaises surprises devant le client.

Je veux la mener personnellement avec Julien, et le client est au courant depuis le début.

Les premiers tests ne sont ni alarmants ni extraordinaires : il y a des coquilles, des cas pas gérés, ça sent vraiment le « pas fini » et c’est bien ce qui m’inquiète. A force de laisser plein de petites choses à faire, on se retrouve avec beaucoup à faire !

C’est à partir de ce moment-là que j’ai commencé à changer de stratégie pour gérer le projet.

La suite au dernier épisode en cliquant ici !

-Jean-Philippe

6 Commentaires

  1. Claire 9 septembre 2014 à 12 h 15 min - Reply

    Vraiment excellent! Quel suspense! Merci de nous faire partager cette expérience terrain.

  2. MATHIAS 16 septembre 2014 à 17 h 58 min - Reply

    Super !!! Je suis bien instruis encore

  3. matthieu 16 septembre 2014 à 22 h 36 min - Reply

    merci c’est très inintéressant je tire une leçon

  4. BENADJAL 17 septembre 2014 à 9 h 21 min - Reply

    Jean,
    Bonjour,
    Le retour d’expérience est très utile dans la gestion de projet, dans le cas des projets industriels le chef de projet organise à la fin du projet une réunion de brainstorming et invite tout le personnel qui est intervenu durant la période d’exécution du projet. Ce personnel décrit les tâches positives et les tâches négatives engendrées durant les différentes phases du projet. Ce brainstorming permet au retour d’expérience pour mener bien les projets d’avenir similaires.
    Merci pour l’article génial que je le trouve très intéressant et bénéfique pour un chef de projet.

    Salutations,
    BENADJAL (Project Engineer)

  5. Darbigué Dieudonné Meunglé 18 septembre 2014 à 19 h 49 min - Reply

    Je suis intéressé et j’aimerais avoir des connaissances en gestion de projet. J’aurais besoin de votre soutien ,merci

Ajouter un commentaire