samedi 3 juillet 2010

Gérer une équipe projet difficile (sans coups de pieds au cul)

Je fais partie d'une agence web interne. On ma confié la responsabilité de construire la première appli iPhone de notre société. Ce projet, qui vient d'être livré récemment à pris 6 mois entre janvier et début juin. Mon équipe était une équipe virtuelle, avec moi comme chef de projet à Paris, nos développeurs en Europe de l'Es et nos clients dans les pays scandinaves. Ce projet, disons le tout de suite, m'a fait vieillir de 10 ans en 6 mois : retards dans les délais, mauvaise compréhension, tensions dans l'équipe ont été monnaie courante tout au long du projet.

Alors même si au final nous avons livré l'appli juste a temps pour être utilisée par nos collègues scandinaves, j'aimerais prendre le temps de lister et analyser les problèmes rencontrés afin d'essayer de leur trouver une solution et faire en sorte qu'ils ne se reproduisent plus à l'avenir. (Qui a dit "Bisounours" ?! C'est bon, tu sors !)

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 ?

2 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.

(Qui a redit "Bisounours"?!)

10 commentaires:

gsempe a dit…

Fantastique article.
Merci pour ton feed-back riche de conseils

Monsieur J a dit…

Wow, voilà qui fait plaisir pour un lundi matin :)
Merci pour ce commentaire gsempe !

stephanie a dit…

Bon sujet !
A vu de nez, comme ça ...je dirai que ce projet manquait sans doute d'indicateurs ?!
Mais pour avoir expérimenté un tout petit peu leur mise en place: je sais ô combien trouver le bon indicateur est difficile ! et surtout un conseil , un indicateur mis en place en debut de projet peut s'avérer completement obsolete quelques mois plus tard !
Un brainstorming avec l'equipe de "techos" auraient peut-etre permis de les impliquer dans le souci de la transparence vis à vis du chef de projet et également à la notion de "projet" qui est peut-etre nouvelle pour eux ?!

Monsieur J a dit…

Hello Stéphanie,

Pas bête, mais à quel indicateur penses-tu ?
Un indicateur qui montrerai l'implication d'une équipe dans un projet ?

Sinon ce n'est pas la notion de projet en elle même qui était nouvelle pour eux, mais plutôt l'obligation de résultat et la notion de deadline non négotiable...

stephanie a dit…

Pour repondre à ta question :
Je fais reference à un indicateur permettant au chef de projet (toi en l'occurence) de savoir si le developpement progresse "nominalement" ou non ...
En l'occurence, j'ai connu un chef de projet qui avait developpé un utilitaire qui venait toutes les semaines compter le nombre de lignes de code produit par son equipe de developpeur ( en toute transparence avec l'equipe :-) En gros ce qui ressortait c'etait que les semaines ou la production de lignes de code etait moindre et bien c'est qu'il y avait un point dur (voir un bug) qui bloquait.
ça vaut ce que ça vaut .....mais en tout cas ça lui permettait d'avoir une vigilence ou un accompaganement renforcee à certains moments du projet avec l'equipe de developpement.
Et puis ça permet aussi à l'equipe de voir que le chef de projet n'est pas là que pour la "representation", mais tient un vrai rôle et a de l'interet pour le boulot de l'équipe.

Je ne sais pas si c'est applicable dans ton cas, et aussi si les equipes auraient été d'accord avec le principe : il ne s'agit pas de comparer 2 personnes entre elles ou encore de verifier que d'une semaine à l'autre le boulot est equivalent .....

Personnellement j'ai essayé de mettre en place des indicateurs sur l'implication de l'equipe dans un projet ; Sous forme de note de 1 à 5 .
Cette methode m'a permis d'ajuster mes comptes rendus et de privilégier le dialogue avec l'equipe et aussi a être plus transparente. Mais aucun indicateur lié à l'avancement propre du projet n'a rellement était efficace ....mais c'est pas faute d'avoir essayer !!

Monsieur J a dit…

L'exemple du comptage des lignes de codes est un bon exemple de quelque chose que tu peux mesure et dont tu connais la valeur totale
Exemple : si j'avais su que mon appli représentait 100 lignes et si j'avais été capable de compter les lignes produites (genre 50 lignes après un mois) j'aurais pu dire que nous avions réalisé 50% de la tâche.
Mon problème était double :
1-Je ne savais pas ce que représentait le travail total (100 lignes ? 200 ? autre chose?)
2-Je n'étais pas capable de compter ce qui avait été produit et j'étais dépendant de ce que déclaraient mes polonais...

Un autre indicateur basique (mais efficace) d'avancement est l'indicateur de la valeur acquise (VA) où :

VA = Avancement physique de la tâche x Budget de référence

L'avancement physique étant compris entre 0 et 1 (basé sur du déclaratif ou pas...on revient toujours à la même chose)

Le point dur semble être la capacité à mesurer de manière non déclarative et indépendante de l'équipe de production.

stephanie a dit…

mouais ....
on fait bien reference au PMI n'est-ce pas ?! comme quoi !!

Guy Perier a dit…

Article très intéressant, sur la base d'une expérience vécue.
En tant qu'ancien manager et maintenant chef d'orchestre, votre article m'évoque le travail d'un orchestre. C'est au chef d'orchestre de créer la réalité du travail d'équipe en instaurant la confiance par la clarté de ses indication, en s'attachant d'abord au confort de jeux des musiciens voire en montant au créneau pour les défendre, en jouant son rôle "d'oreille extérieure", c'est -à-dire en osant les feed-backs. C'est à ce prix d'engagement très personnel que le "miracle" du jeu d'orchestre se met en place.

Monsieur J a dit…

Merci pour ce retour Guy. Tu vois ton commentaire m'a fait beaucoup de bien car hier j'ai eu une réunion en face à face avec un membre de mon équipe à qui j'ai dû faire un feedback difficile.
Et si eux le prennent mal, il ne faut pas croire que le manager le fait de gaité de coeur, mais il serait trop facile de laisser filer, au risque de laisser le collaborateur se complaire dans une situation que vous savez nocive en tant que manager...
Donc un grand merci !

Andrew Rayy a dit…
Ce commentaire a été supprimé par un administrateur du blog.