Réussir un projet – Episode 1 : décider de lancer le projet

 280px-Leaning_tower_of_pisa_2Avant de faire les plans, il fallait vérifier le terrain…

Lors d’une discussion avec un ami à propos de l’aviation civile, activité dangereuse s’il en est, celui ci m’a donné un conseil plein de bon sens : « le secret de la survie en avion, c’est de savoir quand ne pas décoller ».

On pourrait croire que je ne prêche pas pour ma paroisse en écrivant cet article sur la prise de décision, avec comme objectif d’indiquer quand renoncer, mais je préfère les projets qui réussissent, et à l’instar de cette illustration, il existe des projets mourants avant même leur conception. Ce temps de réflexion ne sera pas perdu, il ne s’agit pas de temps supplémentaire, mais d’anticiper une phase qui a lieu quoi qu’il arrive.

Volontairement ici je ne me poserai pas la question du budget, celle-ci sera évoquée lors de mon article sur l’avant-vente. De la même façon je ne parlerai pas ici d’une application grand public, mais bien d’une application métier.
Voici donc les questions à se poser avant de décider de refondre une application, de concevoir une nouvelle application pour un métier existant, ou même d’acheter un nouveau logiciel sur l’étagère.

Commençons par la question évidente : pourquoi ce projet? La réponse à cette question peut être technique (utiliser des outils plus modernes, abandonner une technologie passée de mode ou non maintenue),  mais pour moi si cette raison est la seule, elle ne sera pas comprise par l’utilisateur final. Le pire scénario est pour moi : « prenons cette belle techno toute neuve et faisons de l’isofonctionnalité » : une application doit apporter quelque chose de nouveau.
D’un point de vue fonctionnel, la réponse peut venir d’une volonté stratégique ou d’une demande utilisateur. Il est préférable de mélanger les deux : si le patron veut une application pour créer un nouveau métier, il doit tâter le terrain avant investissement auprès des utilisateurs, et si c’est une demande utilisateur, elle doit être validée par un responsable qui comprend l’utilité de la fonctionnalité demandée.

La deuxième question coule de source : est-ce que mon besoin est suffisamment défini? Un nombre incalculable de prospects (ou clients), répondent à la question « que voulez vous? » par « je veux un CRM » ou « je veux un ERP » ou (mot à la mode) « je veux un algorithme » ou encore « je veux un ERP avec une IHM qui n’est pas une UAG » (le premier qui me donne la signification de tous les acronymes de cet article dans les commentaires gagne 15 minutes de consulting gratuit).
Ceci ne veut rien dire, je peux citer une douzaine de projets de CRM radicalement différents d’un point de vue philosophie de conception et qui sont tous des CRM. Il faut donc avoir une idée précise des fonctionnalités principales, et surtout préparer un discours et un cahier des charges (même peu détaillé) clair et compréhensible à transmettre en avant vente : qui utilise l’application, pourquoi, qu’est ce qui sera stocké, quelle sera la volumétrie de données approximativement. La précision diminue la perte de temps d’explication en avant-vente et vous permet d’être réactif voir proactif dans la suite du projet.

Après le pourquoi, le quoi, voici le quand : quand le projet doit il être fini? J’ajoute même une question subsidiaire : si cette date de finition n’est pas atteignable, quelle serait la date de prochaine finition?
La deadline contribue à la réussite du projet, même si elle est peu réaliste. Par contre il vaut mieux en déterminer au départ au moins deux, même si l’existence de la deuxième date est tenue secrète, cela permet d’une part d’être réceptif à une livraison par lot, d’autre part de pouvoir se retourner rapidement et efficacement en cas de problème en présentant un retro planning cohérent avec l’exploitation.

Parlons maintenant des questions pratiques lors de la conception, de la recette et de l’utilisation finale. La première question est : est-ce que mes équipes peuvent suivre un nouveau projet ? Nous évaluerons lors de la phase d’avant-vente les besoins en fonction de la solution abordée en ressources internes, mais aucun logiciel (même la suite office) ne s’installe dans un entreprise sans un travail de ses collaborateurs : réflexion, choix avant-vente, réunion de suivi des développements, recette, et utilisation attentive avec remontées de bug en production. Beaucoup de projet perdent un temps précieux car les collaborateurs même de bonne volonté n’arrivent tout simplement pas à trouver du temps. Cette question est à rapprocher du « quand », car évidemment la réponse dépend du plan de charge du service et donc de la période de l’année.

Autre question : est-ce qu’il n’existe pas des contraintes pratiques empêchant l’utilisation de l’application? Ces contraintes peuvent être très diverses : doublon avec une application déjà utilisée, données trop complexes ou trop contraignantes à saisir, utilisateur incapables techniquement d’utiliser l’application, trop de cas particuliers trop important pour justifier une utilisation d’une solution automatique, etc…
Une personne talentueuse  mais peu technique nous a demandé un outil de conception automatique d’interface graphique en JAVA. L’outil fonctionnait bien et était conforme à la demande, mais l’utilisateur a constaté qu’il n’avait tout simplement pas les compétences techniques et les automatismes intellectuels pour l’utiliser à bon escient.
Une autre société nous a demandé un outil pour que leur utilisateurs (des monteurs vidéos) saisissent toutes les informations matérielles d’une opération : outils utilisés, temps passés, usure des pièces, salles occupées. Au final les utilisateurs finaux n’ont jamais pu concilier l’urgence du terrain avec la saisie de ces informations.
Enfin une société nous a demandé de créer une application pour gérer la commande de vêtements. Le responsable avait monté un modèle de processus et de devis pour automatiser une grande partie du travail, mais le modèle s’est avéré ne correspondre qu’à une toute petite partie des commandes possibles, et l’application en est devenu inutilisable.
Ces trois projets ont un point commun : ils n’auraient jamais dû dépasser la phase de la réflexion.

Dernière question pratique souvent oubliée mais essentielle : dans le cas d’une refonte, que faire des données existantes? L’exploitation d’une application peuvent permettre d’enregistrer l’équivalent de millier d’heures de saisie, et s’il n’existe pas de processus automatique ou qu’aucune décision stratégique n’a été prise en en ce qui concerne la transition, au moment d’une refonte l’obstacle peut s’avérer infranchissable. Une non reprise des données est vraiment un classique du ratage d’application, il est donc nécessaire d’aborder ce sujet très sérieusement.
Un de nos clients nous a demandé une application de gestion de personnes et de groupes de travail, avec des options de recherche et de catégorisations très intelligentes. L’application a été conçue et réussie, mais le seul problème était que le client n’a jamais pu mettre dans une forme exploitable les dizaines de milliers de personnes et les centaines de groupes créé dans la dernière version de l’application.
Les solutions peuvent être complexes (remise en forme des données, saisie semi automatiques), optimistes (le prestataire saura bien se débrouiller) ou drastiques (table rase), mais il est nécessaire de retenir dès maintenant un point qui reviendra en phase de recette et d’exploitation : la ligne entre l’ancienne et la nouvelle application doit être ferme et marquée (suppression pure et simple de l’application précédente, date butoir, périmètres fonctionnels ou géographiques bien défini). Toute utilisation floue de deux applications en même temps résulte en erreurs, double saisie et données perdues.

Conclusion : rien ne sert de courir, le temps de la réflexion peut avoir lieu avant de décrocher le téléphone pour appeler son prestataire favori, et en plus permettra d’avoir d’ores et déjà la réponse à des questions que tout bon architecte métier vous posera.

Une réflexion au sujet de « Réussir un projet – Episode 1 : décider de lancer le projet »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>