Gestion de projet

Reprendre un projet en crise, ce n’est pas un exercice facile et cela demande de l’énergie. Pour être honnête, pendant longtemps je traînais les pieds pour le faire. En revanche, une fois dedans, c’est très enrichissant comme expérience : généralement on découvre plein d’erreurs à ne pas faire ..

Pour cette étude de cas, d’abord un peu de contexte au moment de la reprise : un projet  de plus de 350 jours, une équipe de 4 personnes chez le client, un engagement au forfait et plus de 40% de dépassement prévu en fin de projet …

Alors oui, il y avait des tableaux excel de suivi avec des indicateurs projets, des calculs de coûts, des courbes et tout ça. Mais en donnée cruciale en entrée il y a encore et toujours le fameux reste à faire. Vous aurez beau avoir les plus beaux outils du monde pour piloter vos projets, si vous et votre équipe ne maîtrisez pas votre reste à faire, vous ne maitrisez rien.

Je ne suis pas magicien !

Quand le projet est sensé être terminé et qu’il y a encore 40% du boulot à faire, faut pas se leurrer, vous reviendrez très difficilement dans le planning et dans le budget, à moins d’avoir une re-négociation musclée avec le client (mais encore faut-il avoir de bons arguments …). Il y a généralement une inertie qui va mettre un peu de temps à se résorber. Comme le Titanic qui essaie d’éviter l’iceberg mais qui met du temps à virer ..

Lire la suite

C’est ce que j’aurais pu me dire compte tenu de la situation ! Mais 1) Paul n’était pas « mon » développeur et 2) il n’avait aucune mauvaise intention à mon égard, enfin .. je crois !

Je venais de reprendre un projet. Le chef de projet avait été envoyé en mission longue durée chez un client et le projet se retrouvait sans pilote. Fort de ma première expérience de chef de projet (vous comprendrez l’ironie …), on m’affecta le rôle de chef de projet pendant cette phase si délicate qu’est la phase de recette.

Je n’étais pas complètement étranger au projet puisque j’avais participé à l’analyse fonctionnelle, la modélisation de la base de données et la reprise de données.

Phase de recette donc. Celle-ci est assez difficile. Les tickets remontés par le client sur le gestionnaire de bugs s’accumulent et les livraisons successives n’arrivent pas à satisfaire le client. Difficile de reprendre un projet au forfait dans ce contexte mais quand il faut y aller, faut y aller …

Parmi les symptômes, plusieurs tickets reviennent d’une livraison à l’autre. Ce qui est sensé être corrigé ne l’est finalement pas. Le client commence à en avoir marre de retester la même chose et il commence à le faire savoir.

La correction d’anomalies : l’histoire sans fin

Je refais donc une passe sur les tickets, je les qualifie, je tâche de les reproduire et les renvoie éventuellement chez le client avec une demande de précisions. Pour les anomalies avérées, je les affecte aux personnes de l’équipe pour correction. Une fois corrigées, les tickets prennent un statut pré-recette. Et avant de livrer, je vérifie que la correction est bien en place pour chacun de ces tickets.

Et heureusement ! je tombe sur des tickets soi-disant corrigés qui ne passent pas les tests. Je vérifie un peu le cas de test, je reboucle avec Paul, le développeur pour le contenu de la spécification et le résultat attendu et je rebascule le ticket à « En cours de traitement ».

Je bascule sur un autre projet. Je reviens en fin d’après-midi sur cette liste de tickets.  Rebelote, je passe en revue les corrections, vérifie que c’est conforme et valide la plupart. Sauf un !