L'art de (se) diriger ( le blog de Laurent Pellegrin)

Je ne résiste pas à la reproduction partielle d'un excellent post du blog de Monsieur J sur "Management et moi" : http://managementetmoi.blogspot.com/ sur le management de projets (ici une appli Iphone sur 6 mois avec des équipes virtuelles sur 3 sites) :

Les problème rencontrés :

1-La mal-compréhension des enjeux business par les développeurs.
Un développeur à Varsovie voit le chef de projet parisien comme une personne qui profite de son travail, qui donne des ordres, boit du champagne et mange des petits-fours aux pots de fin de projets. Si, si, c'est comme ça qu'ils perçoivent les chefs de projet. Le chef de projet est perçu comme incapable de comprendre leurs talents techniques et profitant de leur travail. Inutile de préciser que l'inverse existe également, bien des "techos" étant vus par Paris comme des adolescents boutonneux, à grosses lunettes et cheveux luisants, incapable de faire autre chose que de parler à son ordinateur...
Difficile dans ses conditions de faire comprendre des enjeux business à l'équipe de développeurs essentiellement habituée jusque là à délivrer des projets où les dead lines sont flexibles pour ne pas dire inexistantes

2-Obtenir un feedback
Autre problème : le culte du secret, encore appelé le syndrome Superman. Lorsque vous construisez le plan projet (délais, calendrier) avec vos développeurs, ils considèrent tout retard comme une faute grave, voire un péché mortel. Aussi, au lieu de vous dire de manière transparente qu'ils sont en train de glisser (ce qui permettrait à tout bon chef de projet de prendre les mesures adéquates et de réajuster le planning) et bien non ! pour eux, il est de leur devoir de tout faire pour y arriver coute que coute. Malheureusement, les Superman sont bien rares sur cette terre et les délais ne font que s'allonger, tel le nez de Pinocchio.

3-Tenir le délais
Ce point découle des deux précédents. Impossibilité de comprendre pourquoi une date et pas une autre et manque de transparence sur les difficultés rencontrées égalent délais non tenus. Derrière, qui joue des claquettes aux clients pour leur expliquer que "non, non on doit décaler mais oui oui ils vont avoir leur appli" ?! C'est bibi ! Je t'en foutrais moi du champagne et des petits-fours :)

4-Vendre le projet en interne
Dans mon esprit un bon chef de projet est celui qui sait se créer des opportunités de monter des projets intéressants, qui sait les vendre en interne à sa hiérarchie et qui sait les vendre en interne à des clients potentiels. Un peu comme un entrepreneur qui agirait à l'intérieur de l'entreprise (sur cette notion d'"intrapreneur" voir le super blog de Guy Kawasaki )
Ainsi donc j'ai "piqué" cette idée d'appli à la France (filiale ayant beaucoup de budget et l'ayant acheté pour un one shot), j'y ai mis nos ressources internes et je l'ai transformé pour que cette appli serve plusieurs fois au lieu d'une seule.
Une bonne idée qui a fait ses preuves sur un one shot+ressources internes+extension à une réutilisation sur plusieurs évènements = une hiérarchie convaincue et des clients internes acheteurs de cette bonne idée à moindres couts !

Néanmoins les tensions inhérentes à tout cela (incompréhensions des différentes parties prenantes, difficultés de communication, délais non tenus, colères, pression) on plus fait ressembler ce projet à un Titanic en puissance qu'à une balade en barque sur le lac du bois de Boulogne par une après midi d'été...(la métaphore c'est cadeau !)

Les solutions proposées :

1-Améliorer la communication auprès des "techos"
Je pense qu'il aurait fallu que je replace les développeurs dans le contexte plus large des enjeux et implications d'être compétitifs. Nous sommes tous, dans quelques entreprises que ce soit, au sein de nos services, soumis à une revue de performance continue. Si vous ne prouvez pas votre valeur ajoutée dans l'entreprise, il viendra un jour ou vous serez externalisé, ou pire, que l'on se pose la question de la légitimité de l'existence de votre service pour la société...
Ceci crée donc un besoin d'anticipation et d'évolution. Les dinosaures n'ont pas compris ça, ils sont aujourd'hui au musée...(oui, ok, ils se sont aussi pris une grosse météorite sur le coin de la figure, mais c'est pour la métaphore je vous dis!!)

2-Faire comprendre la notion d'équipe
Un deuxième chantier aurait été celui de faire passer le message de l'équipe. Une équipe c'est un ensemble uni, cohérent et homogène qui travaille ensemble dans le même but. Qui partage les bons et les mauvais moments. Je suis persuadé que si j'avais réussi à mieux leur donner ce sentiment d'équipe j'aurais eu plus de visibilité sur leurs difficultés.

3-Contrôle et Surveillance
Une notion clé en Management de projet. Je l'ai compris maintenant. Quand je leur demandait si tout allait bien, j'aurais du vérifier et ne pas me laisser séduire par le "everything is on track". Pris dans les 1000 taches quotidiennes, on a tendance à faire confiance et à se laisser aller à une certaine indolence. Hors il est du devoir du chef de projet de truffer son plan projet de moments de vérification. Attention à l'effet tunnel...

4-Avec ou sans client ?
Deux manières de faire les choses dans notre agence sont : soit de construire un projet (un site web, une appli iPhone etc...) sans client initiaux, puis d'aller chercher des clients ensuite. Soit de trouver des clients sur la base d'une idée, puis de la construire pour lui. Si la première solution a comme avantage d'être moins impliquante en termes de délais, elle est aussi plus risquée, car à la livraison que se passe-t-il si finalement vous vous êtes trompés et qu'il n'y a personne pour vous l'acheter ? L'autre solution à l'avantage inverse de confronter votre idée à la réalité du business très tôt mais le désavantage d'avoir à livrer ce que vous avez vendu en temps et en heure...

Ces différentes solutions auraient contribué à ce que le projet se passe plus sereinement.

Le mot de la fin

Le travail du chef de projet c'est l'engagement d'une équipe mais aussi la vérification, la responsabilité, le fait de ne pas s'en tenir au "tout va bien" faussement rassurants mais de le vérifier dans sa réalité.
Cette notion de dire que l'on n'est pas content lorsque les choses vont mal est aussi importante. Aussi je vais tenir avec nos techos, maintenant que le projet est fini, une session de "lessons learned" où nous pourrons nous dire ce qui n'a pas été et ce qui a bien marché. Avec pour but d'améliorer nos projets futurs. L'échec a comme vertu qu'il est source d'amélioration.
Enfin tout ceci doit être fait sans lien hiérarchique, puisque le chef de projet n'est chef que transitoirement. Encore plus difficile donc de mener ses troupes, mais aussi plus beau.