Le consultant expert appartient à la communauté des consultants nouvelles technologies

Le cycle en V a-t-il un avenir ?

Le cycle en V a-t-il un avenir ?Imaginez une discussion entre un consultant expert ERP spécialiste et un utilisateur, si on devait argumenter entre agilité ou cycle en V, on n'hésiterait pas longtemps. Pourtant il n'y a pas vraiment une méthode meilleure que l'autre dans l'absolu, il faut choisir celle qui colle le mieux au contexte du projet et aussi à la culture de l'entreprise. Par exemple pour un projet très innovant on se lancera dans une approche itérative avec des prototypes, alors que dans les projets ERP auxquels je participe on partira plutôt en cycle en V.

J'ajoute que pour du BI on peut partir en cycle en V pour une mise en place de base standard puis poursuivre en itératif pour les évolutions au fil de l'eau selon les besoins décisionnels de la MOA. Pour autant on peut aussi fonctionner uniquement en Agile si la structure de l'entreprise le permet (grande proximité MOA - AMOA - MOE > plateau projet).

Le cycle en V a-t-il un avenir ?
Quand on fait de la gestion de projet où tout est compliqué, on se demande si le cycle en V a un avenir

Le choix à faire quand on travaille sur un outil de gestion est aussi lié au mode de fonctionnement Régie vs Forfait selon la culture de l'entreprise. Autant la régie permet les deux modes, autant le forfait vise quasiment uniquement le cycle en V où le triptyque délai / coût / résultat est contractualisé.

Quelle que soit la méthode, la clé se trouve dans 2 principes indispensables : a) Répondre en premier lieu à la priorité du client définie dans le cahier des charges ERP; b) Montrer au client rapidement des résultats. Cela paraît simple. En fait la principale difficulté, selon mon expérience en gestion de projet ERP telle que j'en parle sur mon blog se situe souvent au début des projets : combien ont vraiment construit en premier lieu la structure de base (les "fondations" qui sont si structurantes et si rassurantes pour les informaticiens) sur laquelle tout l'ERP va être construit (les référentiels, la base de données...).

Cela prend du temps, les clients y sont en général peu réceptifs (ils n'ont d'ailleurs souvent pas l'organisation en place pour les faire vivre : cela ne leur semble pas d'une grande valeur ajoutée pour leur propre métier notamment dans le bâtiment). Donc peu d'implication, une lassitude certaine, une informatique qui coûte cher ... et souvent des clients qui ne sont pas prêts (au sens accompagnement du changement) lorsque l'ERP arrive vraiment.

L'autre risque aussi en commençant avec les fondations, est de théoriser ces fondations sur la base de modes de fonctionnement non maîtrisés par les clients (car en dehors de leur coeur de métier). Les règles que l'on peut en tirer peuvent donc être erronées ou compliquées.

La démarche peut pourtant être toute autre si l'on pense que le cycle en V a un avenir : travailler en premier lieu sur le besoin le plus important de l'utilisateur en se focalisant sur la partie visible par le client. Non pas simplement en terme de maquettage ou prototypage, mais réponse complète au besoin. La présenter et la tester avec les clients. Le reste suivra naturellement, dont les fameuses « fondations » ... avec une plus grande chance de compréhension et d'implication des utilisateurs. Il est évident que les premiers développements devront sans doute s'adapter a posteriori, mais au juste nécessaire.

Chez les éditeurs ERP on constate souvent qu'au moins 30% des développements réalisés sont inutilisés, perçus comme très chers, assez peu flexibles etc.

Dans les deux cas, cycle en V et Agile, de nombreuses questions clés sont à se poser :

Selon moi l'agilité ne s'est pas développée contre le cycle en V (à fortiori son effet tunnel) mais pour gérer des cas ou ce dernier est pris en défaut. L'agilité abandonne la certitude et la stabilité du besoin des cycles en V pour d'autres avantages, ce qu'il faut choisir en connaissance de cause au lancement du projet. D'où mon interrogation sur l'avenir du cycle en V. Les réussites et les échecs de chaque type de méthode sont connus et c'est un lieu commun de dire qu'aucune n'est parfaite ni gage de réussite.

Je pense que les deux méthodes sont parfaites en elles-même, en revanche elles négligent de mettre en avant un facteur, prérequis, et de première importance pour un résultat parfait: les intervenants humains au projet devraient aussi être parfaits. 😉 Après toutes mes années de pratique en gestion de projet ERP, en France et au Brésil, je trouve normal que chacun partage son expérience et sa façon d'utiliser, d'adapter les méthodes, de les combiner pour en faire des règles acceptées de tous.

Ce que je retiens de mes lectures et dont je parle sur le blog, ce sont plutôt les faits qui corroborent mon expérience personnelle. Nous ne cessons de changer, découper, modifier, adapter les méthodes de projet autour du seul facteur humain. 😉 Si vous êtes dans le métier depuis longtemps, vous serez d'accord avec moi: il est temps d'admettre la place centrale des personnes impliquées dans un projet. Ce qui implique la structuration des méthodes de projets autour des contraintes portées par les intervenants pour faire aboutir le projet. C'est certes une approche radicale pour répondre à la question initiale que de changer le paradigme de la gestion méthodologique du projet.

Écarter ainsi le suivi de bout en bout d'une seule méthodologie par tous les acteurs pour le remplacer par l'utilisation de toute méthodologie éprouvée, quelle que soit son origine, pour obtenir le meilleur résultat des acteurs à chacune des étapes. Il faut beaucoup d'expérience pour y arriver, et avoir pratiqué les deux méthodologies sans poser a priori que le cycle en V n'a pas d'avenir. Bien des douleurs et des échecs seraient évités si au lieu de se projeter dans « comment faire que mes interlocuteurs répondent à mes contraintes méthodologiques » nous passions à « quelle méthodologie utiliser avec cet interlocuteur pour qu'il me donne efficacement ce dont j'ai besoin pour réussir mon projet ».

Se focaliser sur la partie visible par le client d'accord, mais l'idéal ne serait-il pas de créer notre méthode, celle qui convient à notre entreprise?

Vous êtes spécialiste en gestion de projet ERP ? N'hésitez pas à faire connaître votre point de vue dans les commentaires ci-dessous.

SkypeOutre l'email, mobile, téléphone, Telegram, réseaux sociaux, je vous invite à me retrouver également sur Skype. Très utile, installé sur mon mobile, je reçois instantanément vos messages. Vous n'aurez pas à patienter pour être ajouté. Mon identifiant: michelcampillo.

Aix en Provence, le 3 novembre 2020

Michel Campillo

Michel Campillo Michel Campillo
Consultant chef de projet IT
06 89 56 58 18  contact par email (voir plus bas)

➽ Sur le blog les articles sur les ERP et l'informatique de gestion sont repris chronologiquement, voir aussi les logiciels ERP, faire de la gestion de projet ERP, mon blog dédié à l'écosystème ERP.

Ce billet vous a plu? Alors partagez-le en cliquant sur les boutons ci-dessous:

Facebook Twitter Mastodon LinkedIn

Merci de vos partages! 👷🏻‍

IP du visiteur: 3.143.17.128
Serveur ec2-3-143-17-128.us-east-2.compute.amazonaws.com
Navigateur Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)



🎯 Autres options: Mentions légales, Quelques outils de gestion de projet open source disponibles, À quoi sert une page entreprise Linkedin ?, L'ERP nouvelle génération arrive, Carte mentale, exemples et concept, Intergiciel ERP, Logiciel de prise de notes, Être consultant sur un logiciel métier, Logiciels ERP les plus connus, Les outils en gestion Agile, quelles alternatives?, La quête d'un chef de projet pour la productivité.
✇ Site web 🤖 100% thermo-dynamique 🌱 depuis 2004 🌿

Copyright © 2004-2024 Michel Campillo, tous droits réservés

eXTReMe Tracker