Gestion de projet

Voici les résultats du premier événement inter-blogueurs (et invités !) sur la thématique du rôle de chef de projets !

Je lançais un appel à participation il y a quelques temps de cela suite à un article sur une de mes expériences.

Je suis convaincu que l’expérience des autres est un accélérateur pour votre progression dans le rôle de chef de projets. Et comprendre les conseils au sein d’un contexte, d’une expérience avec une mise en perspective, permet de beaucoup mieux assimiler et retenir ces mêmes conseils.

Lire ces articles, c’est un peu vivre ces expériences vous-même finalement !

Rappelez-vous : l’expérience ce n’est pas ce qu’on a fait, c’est ce qu’on est capable de faire. Il y a donc du bon à apprendre de tout le monde.

Je remercie chaleureusement les participants ! Ils ont trouvé le concept pertinent, ont donc répondu à l’appel et ont eu le courage de se dévoiler pour vous partager leur meilleur conseil issu souvent de leur pire expérience. Je vous invite donc à rester indulgent avec leur récit … la critique est facile, l’art est difficile.

Nous espérons tous que vous en tirerez de bonnes choses ! Sentez-vous libre de contacter en ligne chacun des participants via leur article respectif.

Lire la suite

L’histoire se passe il y a quelques années.

C’était un projet d’organisation documentaire, de rédaction d’une politique documentaire sur les documents clés des processus métiers de la société en question, filiale d’un gros groupe financier. On ne peut pas dire qu’il s’agit là d’un projet planté, mais d’un projet un peu « abîmé » par la situation relationnelle.

Dans le cadre de l’écriture de cette politique, j’avais choisi de mettre en place un collège d’experts internes, en fonction de plusieurs spécialités que j’avais déterminées. Parmi les contributeurs de ce groupe, il y avait une juriste. Préalablement à la réunion de lancement de ce collège, j’avais interrogé chacun des contributeurs séparément.  J’avais demandé à chaque expert de valider le compte rendu résultant de l’entretien. Les renseignements issus des entretiens me permettaient de commencer à alimenter une première ébauche de la politique documentaire.

La partie la plus avancée concernait les aspects juridiques que j’avais donc demandés à la personne interrogée de valider. Or, cette personne prenait du temps à valider sa partie, me rétorquant qu’elle le faisait en surcharge de son travail, bien qu’elle ait été désignée par sa hiérarchie pour participer à ce projet. Cette personne était alors enceinte de son 2e enfant.

« C’est toujours de ses échecs qu’on apprend le plus »

Arrivé à quelques jours de la réunion de lancement, mon chef de projet m’apprenait qu’il ne pourrait pas assurer la présentation, étant par ailleurs occupé sur un nouveau projet en régie. Je préparais donc avec soin la version V0 du livrable, ainsi qu’un support pour expliquer le projet. Je n’avais toujours pas reçu la partie validée de l’expert juridique.

Lire la suite

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 …

Lire la suite