Articles « Info » : Chef de projet

    « Ce qui ressort de la gestion de projet... c'est l'absence de communication avec le client ! »

Pour vous, jeune développeur, Waterfall (1970) vous évoque quelque chose ??
    Bien sûr : dans votre site à l'aspect humoristique un peu cynique de la BD Dilbert, on ne sait jamais vraiment si on doit pleurer ou rire tellement certaines choses sont vraies, notamment le Waterfall.
    J'ai vécu une expérience similaire en tant que développeur, avec un client externe (avec en plus l'aspect 'flip' expose dans 'Chef de projet : expériences itératives').
    Pour moi, le Waterfall illustre aussi un des points récurrents de la gestion de projet informatique, qui est l'absence trop fréquente de dimension "management" des chefs de projet. En l'occurrence, le chef de projet se laisse 'bouffer' par son BB (Big Boss), donc par le "côté management" de l'équipe projet..
    Ce qui ressort aussi, selon moi, c'est l'absence de communication avec le client. 
Dans le scénario du Waterfall, le 'client' redéfinit le cahier des charges N fois qu'il livre au chef de projet sans que celui-ci ne se soit jamais (apparemment) impliqué dans sa réalisation. Ceci m'amène au point que je voulais soulever par rapport à votre site. 

    « La définition du projet ne devrait pas se faire sans une interaction forte entre le chef de projet et le client ! »

Et ce point implique une communication client - chef de projet ?
    Exact.
    Dans la partie 'Le cycle Itératif' section 'Manager un projet', il est dit qu'un projet est fait de trois dimensions :
- l'équipe (de développeurs),
- le sujet (ensemble des fonctionnalités que doit remplir le programme),
- les délais (à respecter... en théorie).
    Il me semble que le client est plus important que le sujet car il est à la source du sujet. La définition du projet ne devrait pas, selon moi, pouvoir se faire sans une interaction forte entre chef de projet et client.
    Ceci pour des raisons de compréhension (linguistique) mais aussi pour éviter des aberrations fonctionnelles. Le client a des attentes mais n'a pas forcement tout le projet en tête (donc risque de redéfinition de cahier des charges) et n'a pas forcement les connaissances pour traduire cela en termes de fonctionnalités informatiques, c'est donc du ressort du chef de projet de s'assurer, au départ, de la stabilité des spécifications et de le verrouiller au mieux.
[Très vrai et cela rejoint la vision de la "qualité à tête chercheuse" de Laurent Bossavit, Coach XP]

Et vous avez un exemple concret de projet... en manque d'itération ?
    Le projet auquel je faisais allusion, est un projet qui a été réalise par ma société pour le compte d'un institution départementale. C'est un projet internet/intranet avec gestion de données institutionnelles. 
    L'aspect principal du projet est qu'il s'est déroule sans accrocs jusqu'à quasiment la date de livraison. Les phases d'analyse et de conception se sont bien déroulées, si ce n'est un nombre d'itérations important sur la partie graphique, ceci n'étant pas bloquant pour la partie purement technique. La phase conception est validée par le client au travers de son DSI qui est notre interlocuteur sur le projet. [cf. remarque de Christophe Thiry]
    Nous sommes maintenant a environ un mois et demi de la date de livraison quand la phase d'implémentation démarre. 
    Je rappelle qu'il y a deux parties sur le projet, une partie internet et une partie intranet.
    La partie internet est réalisée en collaboration avec la Direction de la communication qui surveille étroitement l'image donnée par le site. Cette partie est réalisée sans encombre, mais avec déjà un dépassement sur le délai de livraison (la partie intranet n'étant pas commencée). Le client reste satisfait, et quelques concessions lui sont faites (réalisation de parties non prévues !!!).

    « Et là, tout se gâte... le projet s'est terminé par une rupture du contrat... »

Ennuis en vue, non ?...
    La partie intranet commence donc avec déjà du retard [cf. remarque de Christophe Thiry] et une pression accrue notamment cote management de l'équipe projet (BB, le "Big Boss" du Waterfall) qui voit là des ressources utilisées et non rentables [cf. remarque de Christophe Thiry]. Il est décide que la partie intranet sera livrée par tranche, notamment pour permettre aux agents de faire les saisies pour le site.
[On retrouve une des causes les plus fréquentes de dérives de projets informatiques, ici la 10ème. De plus, la gestion très "ressources humaines" de BB s'oppose à une gestion plus organique et humaine préconisée par XP - Extrem Programming - cf. Laurent Bossavit, Coach XP]
    Et là tout se gâte... En fait, c'est au moment où les parties sont livrées que les incohérences (fonctionnelles) du cahier des charges se révèlent [cf. remarque de Christophe Thiry]. Ces problèmes fonctionnels s'ajoutant aux bugs ou aux fonctionnalités non encore implémentées font que les différents acteurs ne savent plus vraiment où donner de la tête [cf. remarque de Christophe Thiry]:
- Le DSI, a qui les agents remontent des manques fonctionnels et qui retouche le modèle de la base de données avant de s'apercevoir qu'il faut aussi un écran de saisie spécifique [cf. remarque de Christophe Thiry];
- Le manager (BB) qui reprend des ressources aux chef de projet car elles ne sont pas rentables, mais qui lui en redonne parce que le client menace de faire jouer les indemnités de retard
- Chef de projet ne sachant plus ou donner de la tête entre les corrections de bugs, l'ajout de nouvelles fonctionnalités et des effectifs en constant changement.
    Le projet s'est terminé par une rupture du contrat et le paiement des parties effectuées, la fin du projet ayant été confiée à la société chargée de la rédaction du cahier des charges.

Alors, à votre avis, existe-t-il des 'astuces' pour "s'en sortir" malgré tout ?
    Personnellement, je suis arrive à la période ou l'intranet était en cours de réalisation. C'était ma première expérience de développement. Je n'avais malheureusement pas de recul suffisant pour bien voir que les délais de réalisation étaient insuffisants. [cf. remarque de Christophe Thiry]
    Ce que je préconiserais néanmoins en ces cas, c'est d'arrêter tout ! Si l'on en arrive là, c'est qu'il y a un ou plusieurs éléments de la chaîne qui ont un problème. Il est important dans ces cas de faire intervenir une personne tierce qui permette de remettre les choses à plat. La remise a plat consiste a :
- analyser ce qui est fait,
- analyser ce qu'il reste a faire (en prenant en compte les nouvelles demandes fonctionnelles),
- redéfinir les conditions de réalisation 

    Il reste néanmoins, pour moi, évident que les choses se font en amont. Pour information, voici ce que je reproche à ce projet : 
- projet monolithique énorme (>1MF),
- un seul chef de projet, trop jeune et inexpérimenté, pour tout le projet,
- le projet avait été défini dans un cahier des charges pris en main par la DSI, coupant ainsi tout rapport avec les utilisateurs finaux. [cf. remarque de Christophe Thiry]

[Oups, petite remarque : un projet de quelques MF, donc moins d'un ME - mois d'un million d'€ euros! - reste un petit "moyen" projet. Un projet moyen dépasse la dizaine de million d'euros et tourne environs avec 30 à 40 personnes sur 3 - 4 ans. Un gros projet dépasse les 50 ME, et nécessite une bonne cinquantaine de personne sur au moins 3 ans.
Ces repères ne sont pas absolus mais ont juste pour ambition de relativiser l'adjectif "énorme" associé au chiffre "1 MF" (à peine 150000 € ;)
Grâce aux miracles de la relecture avant publication, voici la réponse de Colin Lorrain :]
    Effectivement, dans l'absolu, le projet n'est pas forcément très conséquent. Néanmoins, le 'énorme' s'applique :
    - au fait que, pour ma société, 1MF représente une somme importante, ce qui met une certaine pression sur la partie managériale.
    - au fait que, aussi et surtout (depuis ma vision actuelle de chef de projet), le client a voulu tout faire d'un coup, en un seul projet. [cf. remarque de Christophe Thiry]
    Autant pour moi, donc. Il faut en effet toujours remettre le coût d'un projet dans son contexte. Les chiffres que j'ai cités sont issues de grands industriels ou de banques!] 

    Ce dernier point [à savoir, "le client a voulu tout faire d'un coup, en un seul projet"] est important pour moi. La nécessité d'itérations n'est pas à confiner au seul contexte d'un projet informatique. La mise en place d'un système d'information demande souvent de se poser des questions sur l'organisation en interne et cela se fait rarement en une seule fois (procédures à identifier, personnel à impliquer... [Très bonne remarque. C'est typiquement le genre de situation où des réflexion de type architecturale s'imposent, en particulier pour mieux se poser la question "quel est mon métier ?" (Architecture Métier) et qu'est-ce que mon système d'information doit faire (Architecture Fonctionnelle). Colin Lorrain détaillera ce dernier aspect plus bas en abordant la définition du périmètre fonctionnel du projet.]

    « Tout chef de projet se laisse bouffer par son management s'il n'est pas capable de faire valoir ses besoins. »

Pour vous, tout chef de projet risque de se laisser bouffer par son management ? (son "BB" ?)
    Je crois que l'exemple ci dessus est un bon exemple. Tout chef de projet se "fait bouffer" à partir du moment où il n'est pas capable de faire valoir ses besoins. On en revient ici au triangle Coût/Qualité/Délai. [cf. remarque de Christophe Thiry] 
    Coût et délai sont des variables sur lesquelles client et managers (BB) ont un regard direct (puisqu'ils attendent que le logiciel réponde à leurs attentes donc soit de qualité - je ne m'étendrai pas ici sur la définition du mot qualité-). [En revanche, Laurent Bossavit détaille cette notion et insiste sur l'aspect "répondre aux attentes"]
    C'est au chef de projet de faire valoir ses droits sur le plan des ressources qui lui sont allouées et du délai dont il dispose. Le contexte reste crucial. Si vous avez un BB qui n'est pas souple sur ce plan, soit vous le suivez et c'est sur vous que retombera la faute (non-qualité dans les programmes) soit vous vous imposez et vous "sautez" (à moins que l'on reconnaisse vos qualités de manager et dans ce cas vous ne serez pas longtemps CDP - il est permis de rêver, non ? :-)

    « Évitez le "client-roi", s'adresser au "vrai client (l'utilisateur final). Si vous avez un client obtus, fuyez! »

Comment vous attachez-vous, de votre côté, à mieux écouter le client ? 
    L'écoute du client est avant tout une affaire de communication !

    Un projet informatique est souvent l'occasion d'une rencontre entre deux mondes différents, chaque monde ayant sa propre culture et son propre langage. Établir la communication signifie pour moi arriver à ce que les deux personnes parlent un langage commun. Attention cependant aux clients qui essaient de parler informatique ! La première étape consiste donc pour moi à s'imprégner de l'environnement du client. [Exact, "éviter qu'un client parle informatique" est la raison d'être du cahier des charges, puis des spécifications]

    Deuxième étape, établir l'entente avec son client. Un projet ne peut se dérouler correctement sans une entente, qu'elle soit cordiale ou distante, entre les différents acteurs. Si vous rencontrez un client obtus, fuyez !!! [cf. remarque de Christophe Thiry] Blague à part, à moins que le cahier des charges ne comporte aucune lacune (et encore, les délais ne seront peut être pas respectés), le risque d'être confronté à des problèmes n'est jamais nul. Mieux vaut dans ce cas avoir un client avec lequel il est possible de négocier. L'entente avec son client reste avant tout une affaire de feeling, de personnes et de caractères. [exact, cf. le témoignage d'un chef de projet qui décoiffe !!!] C'est un peu une histoire de couple...

    Une fois ces deux étapes franchies, on peut passer à la définition du projet lui-même.

Ok, alors qui sont vos interlocuteurs durant cette phase de définition du projet ?
    Répondre aux attentes du client, c'est d'abord connaître ces attentes et surtout les identifier. De plus, le client, si il est matérialisé par une personne, se limite rarement à cette seule personne. La première chose à faire est donc d'identifier les différents acteurs du projet.

    Dans un projet, il y a les acteurs "actifs" (ceux qui ont des besoins, utilisateurs en général) et les acteurs "passifs" (ceux qui ne demandent rien mais posent des exigences, un administrateur système par exemple). Le travail du chef de projet consiste dès lors à dénicher toutes les demandes de ces personnes. Il faut donc maintenant interviewer toutes ces personnes en vérifiant à chaque fois que l'on n'oublie rien ni personne. L'expérience du chef de projet joue un rôle prépondérant ici. La rencontre des différents acteurs vous permet aussi de déceler les dissensions internes (l'administrateur réseau n'a pas été impliqué, donc il ne donnera pas d'accès au système - comme quoi, les acteurs passifs peuvent être très actifs !!) encore plus que les incompatibilités matérielles (la base de données existe, mais elle est propriétaire et il n'y a aucun moyen d'y accéder) qui peuvent bloquer votre projet.

    L'acteur le plus précieux reste le VRAI client, c'est à dire l'utilisateur final. C'est souvent lui qui vous révèle que "la page intranet de saisie de prix des produits" dont vous a parlé votre boss et le client est en fait une application complète de gestion de stock [cf. remarque de Christophe Thiry]. Une fois le vrai client identifié (cela peut être plusieurs personnes), la définition fonctionnelle du projet commence.

    Le périmètre fonctionnel d'un projet est souvent une donnée floue. A mon sens, il est important d'essayer de définir le projet au delà des limites données au départ. Cela permet plusieurs choses : - resituer le projet dans un contexte plus global (et donc, de mieux voir les interactions possibles avec d'autres)
- prévoir les évolutions futures
- permettre de s'assurer de la maturité du projet dans la tête du client
Même si il semble au départ évident qu'un client sais ce qu'il veut, on s'aperçoit en général qu'il sait "à peu près" ce qu'il veut, ce qui n'est pas du tout la même chose !
[comme évoqué plus haut, tout cela n'est pas sans rappeler un travail d'Architecture Fonctionnelle]

    A partir des données récoltées, on peut maintenant entrer dans la définition du projet, c'est à dire, circonscrire le périmètre du projet, puis s'enfoncer dans les détails. Il ne faut jamais à hésiter à aller trop loin, il vaut mieux trop en dire qu'en oublier. Cet excès à surtout un avantage, mobiliser le client ! Aller au plus loin avec le client lui permet de mieux prendre conscience de ce qu'il vous demande. Il faut à tout prix éviter le client roi. [cf. remarque de Christophe Thiry]

    Tout cette phase d'analyse ainsi que la phase de réalisation doivent rester le théâtre d'un perpétuel échange avec le client. Les itérations ne sont pour moi que le reflet d'une perpétuelle (et désespérée) tentative d'"accorder ses violons" avec le client car il y a toujours le risque de ne pas se comprendre. Un des signaux d'alarme sont les aberrations fonctionnelles. Je citerai l'exemple du client qui veut "un site sur lequel les gens puissent stocker leurs fichiers". Tentation est grande de penser à un site web, alors qu'un simple serveur de fichier réseau suffit.

Et bien, merci infiniment, M. Lorrain, pour ces avis éclairés et espérons que d'autres développeurs ne manqueront pas de donner leur vision de la réalisation d'un projet en "collaboration" avec le client :)