Dans les derniers billets, nous avons abordé les différentes phases d’un projet conduit avec une gestion de projet traditionnelle.
Comme toute méthode, elle comporte des limites et certains risques. C’est ce que je vous propose de voir aujourd’hui.
Il semble assez difficile de se faire une idée précise des échecs rencontrés avec les méthodes traditionnelles. Des groupes comme le Standish Group ou le Gartner Group ont réalisés quelques études. Il semblerait qu’au-delà de la responsabilité de la gestion de projet, les éléments extérieurs, comme le changement permanent du marché jouent un rôle très important, notamment sur la fragilisation des budgets, apportant également incertitude, vision diminuée ...
Par échec on entend tout évènement qui ferait que le client n’est pas satisfait c'est-à-dire délais et / ou objectifs et / ou budget non respectés.
Selon des études menées par le Gartner Group en 2004 environ 53 % des projets audités dépassent de 189% le budget initialement prévu, 222% ont du retard et 61% possèdent au final les fonctionnalités qui devaient être normalement implémentées (http://puma.tyneo.net/2008_05_01_archive.html)
Même si les projets se terminant bien sont en augmentation, on observe tout de même une stagnation assez importante au niveau des projets mitigés et pas loin de 1 /5 des projets qui sont encore en échec.
Incertitude
Besoins
L’une des principales cause est liée à l’incertitude concernant les besoins et la définition des exigences.
En effet la plupart des clients expriment des difficultés quant à la définition de leurs besoins. Mais cette réaction est normale. On ne peut pas tout connaître dès le départ. Ils émergent au fur et à mesure qu’on avance dans la création du produit.
Dans la majorité des cas le représentant du client n'est pas l'utilisateur final. Partant de là, il ne connait pas précisément le besoin réel. Tout n'est pas clair dans sa tête. Pourtant avec ces méthodes, le client et le fournisseur vont dépenser beaucoup d'énergie pour détailler au maximum les besoins afin d'obtenir des exigences plus ou moins bien rédigées dans un cahier des charges et même parfois par un simple mail.
Pourquoi le client agit-il ainsi ? Je pense que c’est certainement par peur d'oublier quelque chose. Il sait que la liste ne pourra pas être mise à jour sans un avenant au
contrat. Quand on veut tout détailler, il y a un moment où on est dans ce qu'on appelle une phase de sur-spécification.
A l'opposé, le client peut ne pas indiquer beaucoup d’informations. Comme le cas précédent, on peut se demander pourquoi. La personne chargée de cette tâche ne doit pas se sentir concernée et donc ne s’investit pas dans le travail qu’elle devrait fournir. Un projet qui est dans cet état ne devrait même pas démarrer. On ne doit pas imaginer le produit pour le client.
Même si les méthodes classiques ont évoluées notamment avec l'utilisation du modèle en V, on essaie d'éviter tout changement et de se tenir au plan. Tout a été planifié de bout en bout et le moindre changement important pourrait coûter cher, avec une nouvelle phase de revue des exigences, des documents à mettre à jour et une nouvelle validation à donner.
En 1987, un homme nommé Barry Boehm démontre que le changement a un coup et que ce coût augmente de manière exponentielle au cours du temps dans le projet. Il semblerait que la correction d’un changement qui arrive lors de la phase de tests finale du produit peut alors coûter jusqu’à 700 fois plus chère, que si le besoin avait été initialement décrit lors de la phase de définition des besoins et des exigences.
Même si les coûts ne sont pas 700 fois plus chers, ils existent Cette situation a été vérifiée plus d’une fois, notamment lors d’une expérience personnelle. Face à ça les différents intervenants ont une réaction logique : empêcher le changement.
La vérification et validation des documents est la conséquence de cette prévention. La volonté de contrôler le projet du début jusqu’à la fin, ajoute de la rigidité à la gestion de projet. Une fois terminés, très peu de projets sont conformes aux attentes du client. Cela signifie que le client n’est pas satisfait et on peut considérer ça comme un échec.
La solution à mettre en place : autoriser le changement. L’utilisateur peut supprimer des éléments parce qu’il s’avère que finalement tel ou tel besoin est inutile ou au contraire en ajouter suite à un oubli de sa part.
Un autre point important concerne la hiérarchisation et priorisation des besoins. Celui-ci est prioritaire, celui-là peut attendre. Qu’est ce qui a le plus de valeur pour le client ? Avec ces méthodes classiques, il n’y a pas cette notion. Tout est important, je veux tout, le plus vite possible. Les développeurs vont alors prendre eux-mêmes la décision, qui se base la plupart du temps sur des choix techniques. Au final, si le projet doit être terminé pour une raison quelconque, temps, budget …, le chef de projet aura la responsabilité de supprimer des fonctionnalités qui malheureusement pourraient avoir beaucoup de valeur pour l’utilisateur. Le client s’il le souhaite doit pouvoir refaire la priorisation de ses besoins.
En plus des problèmes que l’on peut considérer comme internes au projet, il faut prendre en compte l’environnement extérieur, le marché auquel le produit développé appartient. En effet le marché évolue de plus en plus vite et si le client
veut rester dans la course il n’aura d’autre choix que de modifier certains de ses besoins pour s’adapter. On s’aperçoit alors que le modèle de gestion de projet choisi n’est pas en adéquation, puisque le chef de projet veut se tenir au plan le plus possible.
Ce phénomène qu’on appelle l’effet tunnel s’applique très bien dans le monde du logiciel, où il n’est pas rare de voir des projets qui s’étalent sur plusieurs mois, et parfois plusieurs années.
Les Hommes
Le produit développé appartient à un domaine qui peut être inconnu aux collaborateurs. Auront-ils une autonomie suffisante ? Il est difficile de répondre à cette question et donc de définir le niveau de productivité qu’aura l’équipe sur le projet. Et ceci est encore plus vrai qu’il n’y a pas de retour client, donc pas d’apprentissage du métier possible par cette voie là. Pour avoir travaillé sur des logiciels intégrant des fonctionnalités de la finance, certains besoins spécifiques demandent une connaissance métier plus ou moins poussée.
La technique
Les technologies utilisées sont elles maîtrisées ? Si le projet est construit sur des connaissances techniques solides, il ne devrait pas y avoir de problème. Dans le cas contraire l’équipe à besoin de temps pour se former et intégrer ce nouveau savoir dans le produit. Le risque de bogue est plus important. Cet apprentissage est d’autant plus long que l’architecture du produit est complexe.
Planification
Pendant la phase de planification un plan détaillé des étapes à venir a été créé. Or c’est bien connu qu’il est difficile de tout prévoir dans le logiciel par rapport au projet et à son environnement. Partir du principe que tout peut être planifié, est risqué. Vous allez réaliser votre plan, vous y tenir le temps que tout se passe bien. Mais que va-t-il arriver le jour où un problème important sera levé ? Vous allez tout simplement tenter de suivre votre plan. Mais au cours du temps, vous allez dériver, et dans le pire des cas le projet va échouer.
Au final, le client sera insatisfait parce qu'il n'aura pas le produit escompté au départ. Pour le fournisseur les imprévus risquent d'engendrer des délais supplémentaires et des dépassements budgétaires assez fréquents sur les projets.
Communication
Dans un projet la communication est très importante.
Peu importe le type de projet, le représentant du client et le fournisseur parlent des langages différents. Fonctionnel d’un côté et plus technique de l’autre. Comment être certain qu’on s’est fait comprendre ? Si j’ai bien compris mon client veut que je lui développe telle fonctionnalité….. N’ayant pas de livrable avant la fin ou même un prototype, le client ne peut pas faire de retour sur ce qui a été développé. On se trouve alors dans une situation, où comme il n’y a aucune communication avec le
client, on ne sait pas si ce qui a été fait correspondait exactement à ce qu’il souhaitait. Le risque que le client soit totalement insatisfait lors de la livraison est élevé. Il y a de fortes chances que le fournisseur doive faire des modifications de dernières minutes, monopolisant du temps, des ressources et donc de l’argent dépensé inutilement.
Qualité
Comment définir la qualité finale du produit ? J’aurai tendance à dire qu’elle se mesure par rapport à la satisfaction du client.
Selon Véronique Messager Rota cette satisfaction est composée de trois contraintes, les trois C: contenu, calendrier et coût.
Avec les méthodes classiques le chef de projet se conforme au planning créé au départ, donc normalement, aucun changement ne devrait être effectué. Dans le cas contraire, le calendrier doit être adapté. On est en contradiction avec la date de livraison communiquée au client au départ.
Comment faire si on ne veut pas modifier le calendrier. La solution envisageable serait d’adapter le contenu du projet. Mais que deviennent les besoins déterminés par le client. Quelle fonctionnalité, va-t-on décider de supprimer ?
Dans tous les cas le client ne sera pas satisfait parce qu’au final, le développement, va lui coûter plus cher, si les ressources sont affectées plus longtemps, ou bien il n’aura pas l’outil souhaité et pour lequel il a passé un accord avec le fournisseur.
Dans un processus en cascade, il y a une phase de test qui est réalisée, une fois les développements terminés. Cette étape qui arrive juste avant l’intégration est effectuée tardivement. En procédant ainsi, la détection et surtout la correction des bogues peuvent s’avérer fastidieuses. Comment faire pour corriger le bogue sans risquer de faire des régressions dans le code ? Ces corrections prennent donc beaucoup de temps et par conséquent coûtent beaucoup plus cher que si on avait
testé tout au long du développement.
Plus un projet dérive dans le temps et plus son taux d’anomalies est important. Le coût des corrections augmente également, puisque les bogues sont plus difficiles à trouver, à corriger…
Les coûts et les délais sont non métrisés. Au final temps et argent sont perdus pour le client comme pour le fournisseur.
Rigidité et lourdeur de la démarche
Aujourd’hui, nous vivons dans un environnement qui évolue tous les jours à grande vitesse où la pression concurrentielle est de plus en plus forte. Il faut changer, s’adapter pour y faire face. Ces changements peuvent provenir d’évolutions technologiques, d’une nouvelle stratégie, de nouveaux besoins utilisateur. Or on a vu qu'avec l'application de ces méthodes et l'exécution de tâches successives, on obtenait exactement le contraire. On se tient au plan.
En agissant ainsi, en faisant abstraction de ces changements, on fait preuve d'aucune réactivité. La performance n’est pas présente. Sur un projet long terme, on risque tout simplement de se retrouver avec une application qui à sa sortie sera déjà obsolète et donc sans aucun intérêt pour l'utilisateur. Résultat, un véritable échec pour le projet, et donc pour le client.
On retrouve également cette lourdeur dans la réalisation des différentes documentations. Entre le cahier des charges, les documents techniques, les différents documents de validation pour les étapes de conception et autres. On est vite noyé sous un nombre impressionnant de papiers. Alors bien surs il ne faut pas supprimer la documentation mais est ce bien nécessaire d’en faire autant. Réaliser une bonne documentation demande beaucoup de temps, avec les inconvénients que cela engendre : ambiguïté du langage, coût de la rédaction, coût du maintien en accord avec la réalité, etc. Parfois ils sont rédigés seulement à la fin, alors qu’ils devraient être complétés pendant le projet dès que la fonctionnalité est stable.
Rédiger le document tardivement engendre une perte d’informations.
Un client oublié
Un des points négatifs majeur avec les méthodes traditionnelles, concerne la relation avec le client. On le voit pour le recueil des besoins, éventuellement pour fournir un cahier de tests dans le cas du modèle en V, et quelques fois sur des points qui peuvent sembler critiques. Mais à partir de la phase de conception les vérifications et validations deviennent plus techniques, celui-ci est donc exclu.
Comment un client peut-il se satisfaire de cette situation ?. Il ne peut pas donner ses appréciations, faire des remarques qui permettraient d'améliorer la satisfaction par rapport au produit. Un client qui connait, voit son produit se construire sera plus motivé à l'utiliser
Dans le prochain billet je vous ferai part d’une expérience personnelle, montrant les limites que l’on vient d’expliquer.