Michel Operto – Le conseil que je donnerais au chef de projet que j’étais

Le chef de projet aux commandes ... ou pas !Comme dans les crash aériens, les crash de projet proviennent souvent d’une conjonction et / ou succession d’événements. Ceux-ci pris individuellement ne causeraient probablement pas de dégâts irrémédiables mais, lorsqu’ils se cumulent, ils parviennent à tuer votre projet.

C’est exactement ce qui m’est arrivé il y a plus de quinze ans sur un projet de déploiement de progiciel pour automatiser l’envoi sur le terrain de techniciens de réparation de terminaux bancaires.

La première erreur fut d’avoir un message ambigu. Les communications sur l’objectif du projet mentionnaient deux éléments :

Une meilleure qualité de service (sélection du technicien le plus proche du site client, ayant les compétences requises et les pièces détachées jugées nécessaires) ET une meilleure productivité de nos équipes techniques. Le message retenu par les équipes techniques fut limité à la seconde partie de l’objectif : meilleure productivité = plus de pression = moins de staff = mon job est à risque…

La seconde erreur fut technique. L’algorithme de détermination du meilleur technicien en fonction de sa géolocalisation se basait sur des données liées au temps moyen de déplacement entre deux codes postaux (celui des techniciens disponibles et celui du site client). Hélas, la base de donnée installée par le fournisseur comportait des erreurs pour certaines régions (qui ne faisaient pas partie des tests et pilotes initiaux…). Les techniciens se retrouvèrent assignés à des tickets d’intervention qui leur prenaient bien plus de temps de déplacement que ne le pensait le système automatisé.

La troisième fut un loupé dans la communication vers certaines parties prenantes. Les responsables de comptes clients, bien qu’identifiés comme critiques, ne reçurent pas suffisamment de communication sur le projet et les bénéfices attendus pour eux et leurs clients.

Voici ce qui se produisit lors des premiers jours de vol …

L’erreur technique sur les temps de déplacement entre codes postaux fut amplifiée par les techniciens qui ne voulaient pas que leurs zones d’intervention changent et qui craignaient pour leurs postes. Ils mirent en avant des exemples de non-respect d’engagement de service attribuables au nouveau système sur certaines interventions. Leurs clients s’en firent l’écho auprès de leurs responsables de compte menaçant de pénalités de retard. Ceux-ci mal informés sur les tenants et aboutissants du projet mirent une telle pression sur le management que le projet fut immédiatement stoppé et relégué aux oubliettes !

Conseil au chef de projet que j’étais : la communication, la communication, la communication, et ce, vers toutes les parties prenantes.

Michel manage des projets informatiques depuis plus de deux décennies. Nombre de ses missions ont impliqué des séjours prolongés à l’étranger : USA, Angleterre, Japon, Pays-Bas et bien d’autres. Il détient une certification PMP® (Project Management Professional) et a fondé PMI France-Sud dont il fut le président pendant plusieurs années. Plus récemment, il a obtenu les certifications ITIL et Prince2. Professionnellement, sa passion est le management projet et le leadership. Il anime un blogue réputé sur les meilleures pratiques de management de projet http://DantotsuPM.com ou http://leblogdumanagementdeprojet.com

Cet article participe à l’évènement inter-blogueurs “le conseil que je donnerais au chef de projet que j’étais” organisé par ce blog. Si vous avez aimé cet article et souhaitez voir les autres articles de cet événement, je vous remercie de cliquer sur ce lien : j’ai aimé cet article !

1 réflexion au sujet de « Michel Operto – Le conseil que je donnerais au chef de projet que j’étais »

  1. Pour ma part, j’ajouterais que le chef de projet doit être très persévérant, tout en sachant changer de direction ou abandonner si nécessaire. Par ailleurs, rien de mieux que des « quick wins » pour motiver ses troupes !

    Répondre

Laisser un commentaire