Lors des précédents billets nous avons fait une description de la gestion de projet traditionnelle, de ses limites et de ses risques.

Dans ce nouveau post, je vous propose de décrire une expérience personnelle.

1. Contexte du projet

 Il y a maintenant deux ans j’ai travaillé sur un projet pour la création d’un site de vente en ligne. Ce projet qui au départ devait se dérouler en quatre mois, nous a pris presque deux mois supplémentaires. Besoin non prévu au départ, développements inutiles et supprimés, avenants multiples….Résultat constaté. Dépassement des délais, dépassement du budget initial et bogues qui coûtent chers.

2. Se poser les bonnes questions

Dans le livre gestion de projet, vers les méthodes agiles, l’auteur (Véronique Messager Rota) nous propose de se poser quelques questions afin de mettre en évidence les points positifs, mais également ce qui ne va pas. Je vais tenter de répondre à certaines de ces questions, pour faire ressortir ce qui a causé l’échec partiel de ce projet et les inconvénients

des méthodes traditionnelles.

Les réponses à ces questions devraient nous permettre de rechercher des voies et processus d'amélioration.  

Quelle est la vision de votre projet ?

Au départ, on a comme objectif de réaliser un site e-commerce pour de la vente privée en ligne. La marque possède un magasin et souhaite élargir sa clientèle en passant par internet. Ayant déjà une base utilisateurs, les premiers clients seront ceux du magasin qui petit à petit feront connaître le site entre autre par un système de parrainage.

On connaît les pages principales que le client souhaite avoir, mais le contenu de ces pages reste assez schématique. Je voudrais ca, mais peut-être que ceci serait mieux….

Ce sont les seules informations que l’on a.

Le client a quelques idées supplémentaires qui seront décrites dans le cahier des charges, mais ses idées ne sont pas bien expliquées. La compréhension des besoins n’est pas réciproque.

Dès le départ on sait que l'on sera obligé de revenir dessus pour y apporter des précisions. Pourtant malgré cette incertitude, ce manque d’information flagrant, les documents sont validés et signés. Le début du développement est déjà prévu pour le début du mois prochain.

Est-ce que le délai de réalisation est défini ?

Contraint par le marché, nous avons un délai de quatre mois à partir de la signature pour réaliser le projet et le livrer. Le chef de projet ne peut affecter que 2 personnes à plein temps, les autres ressources étant déjà affectées sur d’autres projets.

Le client a bien insisté sur le délai qui se doit d’être fixe pour ne pas prendre de retard sur la concurrence. On est dans une situation où le délai est fixé, mais sans connaître précisément le périmètre fonctionnel. A ce moment là le lancement du projet ne devrait tout simplement pas se faire. Le chef de projet sait très bien les problèmes auxquels il va devoir faire face. Déjà avec des besoins clairement exprimés, il est assez difficile de se prononcer précisément sur les délais, mais il est impossible de dire si dans notre cas il sont réalistes ou pas. 

Est-ce que l’expression des besoins est rigoureuse ?

On sait très bien que déterminer tous les besoins dès le départ est impossible et on risquerait de tomber dans le piège de la sur-spécification comme on a vu dans ce billet lors de la description des limites. Dans notre cas, c’est le contraire, certains besoins du client sont absents, d’autres sont pas du tout précisés. Qui nous dit qu’à la fin on aura vraiment ce qu’il souhaitait. Les besoins exprimés auront certainement évolués. Plusieurs petites réunions ont été faites, pour réfléchir, essayer de faire ressortir le besoin désiré, quelques fois avec succès.

Par ailleurs aucune priorisation des besoins. Comme c’est souvent le cas avec ce mode de management, tout doit être fait le plus vite possible, tout est important.

La relation avec la maitrise d’ouvrage ?

Lors de la phase de recueil des besoins, le client était plutôt dans le style collaboratif. Beaucoup d’échanges avec le chef de projet pour l’aider. Mais au cours du projet la relation est devenue plus tendue. En effet on avait d’un côté le client qui ne savait pas réellement ce qu’il voulait, et de l’autre un chef de projet qui se tenait à ce qui venait d’être validé une nouvelle fois et dont le développement était en cours. Les différents avenants pour supprimer et recommencer à chaque fois certaines fonctionnalités ont créés des tensions.

Comment s’est déroulée l’élaboration du planning ?

La création du planning a été une tâche difficile, demandant beaucoup de temps. Elle s’est appuyée sur des éléments qui n’étaient pas stables. Une fois créé, on s’est rendu compte qu’il était obsolète.

Tout au long du projet, nous avons eu des modifications à faire ce qui a engendré des conséquences sur la date de rendu du produit. Finalement, la livraison du produit s’est faite avec plus de deux mois de retard sur ce qui avait été prévu initialement. Le planning a du être refait pour correspondre à la réalité. Que de temps perdu. C’est là qu’on se repose la question de la planification détaillée, même dans les cas où on est presque certain que ca n’évoluera pas. Pourquoi ne pas plutôt détailler son planning sur une courte période, trois semaines par exemple. Pour la suite on ne met que les jalons importants. Ainsi, on éviterait de perdre du temps comme ca été le cas sur le projet auquel j’ai participé.

Quel rythme pour les livraisons ?

Au niveau du contrat une seule livraison a été prévue. Celle correspondant à la date limite fixée par le client au départ. Le site est dans un premier temps mise en place sur une plateforme de pré production. Le rythme imposé signifie qu’il n’y aura pas de livraisons fréquentes d’un produit fonctionnel et donc par conséquent, il est impossible de montrer quelconque progression dans l’avancement du projet au client.

Nous ne pouvons pas faire voir notre capacité de réalisation et d’amélioration. Cette méthode de travail, augmente les risques, avec la possible découverte de mauvaises surprises tout à la fin du projet.

Comment ont été réalisés les tests ?

Les tests sont arrivés que très tardivement. Autant dire que la correction de certains bogues nous a demandé du temps. Je ne pense pas que les tests nous aient coûtés particulièrement chers. Ce sont surtout les corrections qui ont été apportées pour les différents bogues, les non-conformités avec ce que le client attendait du produit. La découverte de ces bogues après des mois de développement ou certaines fonctionnalités ont été redéveloppées à plusieurs reprises est vraiment frustrante,et ne motive pas dans la correction.

Certaines corrections ont engendrées des régressions sur une version du site mise en production. Ainsi, plusieurs milliers d’euros ont été perdus. En effet une partie du code qui gère le panier pour stocker les produits à acheter ne prenait plus en compte un cas particulier lié au parrainage des utilisateurs. Avec ce bogue, on a du faire une correction et quelques tests supplémentaires dans l’urgence, afin que le site soit fonctionnel le plus rapidement possible.

La satisfaction du client ?

Le client n’est pas satisfait sur certains points de l’application. Mais comment peut on être satisfait de quelque chose à partir du moment où l’on change d’idée régulièrement. S’il n’est pas satisfait c’est le résultat d’un cahier des charges mal rédigé initialement avec pour conséquence une non conformité des besoins….

La gestion de sous-traitants?

A l’époque du projet, l’entreprise n’a pas de graphiste. Elle décide donc de sous traiter la réalisation de la charte graphique du site à une personne extérieure. Mais les premiers résultats sont longs à arriver ce qui retarde l’intégration du site et la mise en page des fonctionnalités qui sont développées. Le graphiste ne travaille pas dans les mêmes bureaux que le reste de l’équipe, la  communication est donc plus difficile.

Après cette série de questions on pourrait déjà mettre en évidence des pistes d’amélioration, mais nous allons continuer un peu plus loin, en apportant des réponses supplémentaires sur l’organisation, l’équipe et le client. Elles devraient nous confirmer que l’environnement du projet n’est pas en adéquation avec les objectifs initiaux du client.

Dans quel type d’organisation évoluons-nous ?

Pour mener à bien le projet, il faut faire face à d’importantes procédures. L’organisation est de type hiérarchique et bien que celle-ci ne soit pas très élevée, il  y a un certain temps entre le souhait exprimé par le client, la validation technique,la validation budgétaire et le moment où la fonctionnalité va effectivement être intégrée dans le cycle de développement.

On ne peut pas dire que le changement soit la ligne de conduite, bien au contraire,on est plutôt dans un style où on a établi une feuille de route et on doit s’y tenir.  Mais comment suivre un plan que l’on sait obsolète depuis le début, de part le manque de précision dans la définition des besoins.  La notion de valeur ajoutée pour le client n’existe pas. Pas de valeur business ou de  priorisation quelconque des tâches. Les développements sont réalisés dans l’ordre où le chef de projet nous les donne.

Quel est le profil des différents chefs de projets. ?

Le chef de projet a très peu d’expérience. Il a déjà travaillé sur plusieurs projets de petites tailles. Il est plutôt dans un style de management directif et laisse donc peu de marge de manoeuvre à son équipe, qui finalement n’est pas très autonome.

Comment sont constituées les équipes ?

L’équipe travaillant sur le projet est composée exclusivement de stagiaires.  Initialement le projet devait durer le temps de notre stage. Or on a vu que celui a  finalement pris plus de temps que prévu. L’entreprise a donc du faire appel à de nouvelles ressources. Pour les nouvelles personnes intégrées, il y a un temps d’adaptation qui même si il est assez court, retarde encore le projet.

Est-ce que le client est accessible ? Quel est le degré d’implication des utilisateurs.

Sur la totalité du projet le client n’était disponible que quelque fois par téléphone ou par mail. On peut alors se demander comment obtenir un produit satisfaisant pour le client et les utilisateurs, surtout qu’il ne faut pas oublier que le cahier des charges a mal été rédigé.

Le client s’est impliqué dans le projet au départ puis seulement à partir de la phase de mise en pré-production, phase pendant laquelle il a été constaté que des fonctionnalités ne correspondaient pas finalement à ce qu’il souhaitait. Suite à ces bogues, le client venait tous les jours pour nous retourner toutes les erreurs qu’il pouvait trouver en naviguant sur l’application.

D’un point de vue utilisateur, il était difficile de certifier que ce qui était développé correspondait aux attentes du client final, étant donné qu’aucun n’a été intégré dans le projet. Les premiers retours n’ont été disponibles qu’après la mise en production du site. La plupart du temps il s’agissait de problèmes ergonomiques,paramètre sur lequel l’équipe n’a pas consacrée suffisamment de temps.

3. Echecs internes

Les problèmes rencontrés avec le client et ses besoins ne sont pas les seuls facteurs.

En effet, plusieurs points sont à souligner :

Le premier d’entre eux concerne l’inadéquation des ressources affectées à ce projet. A l’époque le meilleur développeur pouvant faire usage de ses compétences n’est pas disponible, car il travaille sur un projet interne qui lui prend beaucoup de temps. De plus, le chef de projet est peu expérimenté et les développeurs, dont moi, ne sont que des stagiaires ou des développeurs juniors n’ayant jamais travaillés sur un projet de cette taille.

A tout cela il faut ajouter les technologies utilisées. Certes innover avec les nouvelles technologies peut amener un plus au produit. Mais quand elles ne sont  pas encore stables et pas bien maîtrisées, on prend des risques supplémentaires inutiles, sans compter le temps d’apprentissage.

L’équipe n’est pas aussi productive qu’elle le souhaiterait. Les développeurs manquent d’expérience et l’autonomie n’est pas encore totale.C’est tout cet ensemble d’éléments qui fait qu’on se retrouve avec un projet pas simple du tout à gérer. Au final, on se rend compte que les décisions qui ont été prises n’étaient pas les bonnes.

4. Convictions

Quand on voit les réponses apportées aux différentes questions, et la situation du client au départ, il est clair que la méthode de management utilisée ici, la méthode en cascade, n’est pas du tout adaptée à la situation du client.

Premièrement, le client nous impose une date pour des raisons de concurrence sur le marché. Dans ce contexte, il serait mieux de se baser sur un développement itératif qui nous permettrait d’avoir une première version stable rapidement. Cela donnerait l’occasion au client de mettre une première version en ligne, certes incomplète par rapport à ce qu’il escomptait au départ, mais il ne se retrouve pas avec un produit inutilisable.

Ensuite compte tenu de la précision des besoins, de la connaissance réelle de l’application qu’il a, on sait de manière certaine que des changements sont à prévoir. Or la planification qu’on essaie de mettre en place depuis le début ne s’y prête pas du tout. En démarrant le projet, le chef de projet a pris de gros risques qui on a pu le voir nous ont apportés des conflits de manière quasiment permanente pendant et surtout à la fin du projet. Certaines décisions ont été prises sur des suppositions qui malheureusement n’étaient pas les bonnes.

Nous ne pouvons pas tout savoir et nous aurions du être plus attentif à ses impératifs métiers. Cette expérience a le mérite de nous montrer au moins une chose. Faire une application qui soit au plus vite fonctionnelle avec des tests effectués régulièrement dès les premiers développements. On obtiendra ainsi un logiciel utile, de qualité et qui a de la valeur pour le client. Mais encore faut il que l’équipe de développement et le chef de projet jouent le jeu. Le développement au forfait à partir d’un cahier des charges, est dommageable aux deux parties dans la plupart des cas.

Le prestataire fait des offres fermes sur un  périmètre mal connu mais il s’appuie sur le fait que celui-ci va bouger pendant le projet pour s’assurer contre les dérives en prévoyant de facturer des avenants au contrat lorsque les expressions de besoin se révèleront incomplètes ou inadaptées.

Le client de son coté, sait qu’il devra payer en plus toutes les fonctions qui n’étaient pas dans le cahier des charges et va donc lister tout ce dont il pourrait peut être avoir un jour besoin. Il oublie cependant que ces demandes vont être chiffrées par le prestataire, alors que le client n’en a finalement pas l’usage aujourd’hui et n’en aura peut être jamais l’usage !

Dans cette approche contractuelle, c’est donc toute la relation client / fournisseur qui est biaisée, dès l’origine.

Nous allons voir qu’il existe d’autres méthodes et plus particulièrement les méthodes dites Agiles qui proposent une autre vision de la gestion de projet, mais qui ne sont pour autant incompatibles avec la notion de contrat au forfait.