Une récente étude menée pour le compte de Computer Associates auprès d'une centaine de directions des systèmes d'information (DSI) de grandes entreprises montre qu'un tiers des projets informatiques dérapent en termes de respect du budget et des délais. Pour 25 % de ces projets, le coût à l'arrivée aura doublé. Pire, 10 % n'aboutiront jamais.
Pourquoi ces projets dérapent-ils ? Quelle que soit la nature du projet - site web, application métier, etc. - on retrouve toujours les mêmes raisons,
Un besoin mal défini, des règles de gestion spécifiées sans tenir compte de l'outil utilisé, l'évolution du périmètre fonctionnel en cours de projet et l'intervention d'autres interlocuteurs en cours de projet qui ne possèdent pas tout l'historique du dossier.
1. Mal définir son besoin
La première pierre d'achoppement des projets informatiques est souvent une mauvaise définition du projet. La réalisation des cahiers des charges dont la précision varie du simple au double d'une rubrique (site web) ou d'une fonction de service (application métier) à l'autre. Résultat, certaines sont trop détaillées alors que d'autres sont à peine évoquées entreprises n'arrivent pas à déterminer la typologie de leur projet : s'agit-il d'un intranet de communication, d'une application métier, d'un site web ?
Ce qu'il faut faire :
- Commencer par caractériser le projet, quitte à être légèrement caricatural. Une vision claire de la typologie du projet permet de guider plus aisément les prestataires ou les équipes internes. Elle permet également de se poser rapidement les bonnes questions et d'isoler les pièges à éviter.
- Définir ensuite avec précision - mais sans excès - le besoin : fonctions de services, contraintes, règles de gestion, public visé, etc.
2. Se précipiter au début du projet pour tenir les délais
Il n'y a rien de pire que de vouloir à tout prix tenir le budget et les délais en précipitant les phases amonts du projet. C'est la meilleure façon de ne pas y parvenir. Il est fondamental d'investir sur les premières étapes de spécifications et de mise en place du projet. C'est la meilleure façon pour éviter 80% des problèmes que l'on risque de rencontrer par la suite.
Ce qu'il faut faire :
Ne pas remettre à tout prix les spécifications dans les délais si elles ne sont pas complètement analysées. Mieux vaut perdre du temps pendant cette phase d'analyse plutôt qu'en fin de projet où cela peut être beaucoup plus coûteux.
Prendre le temps de bien spécifier les aspects fonctionnels et ne pas s'appuyer sur les fonctions du progiciel pressenti pour gagner du temps.
3. Sous estimer la charge, le coût, et l'implication nécessaire
La réussite d'un projet repose à la fois sur le temps et les moyens financiers qu'on lui alloue et sur l'implication des équipes en interne. À trop vouloir économiser sur le budget, on se retrouve souvent à devoir réaliser le projet en interne, même si l'on manque de certaines compétences.
Mais ce n'est pas le seul danger. L'absence d'interlocuteur coté utilisateur, le manque de disponibilités ou encore des interlocuteurs trop nombreux et sans chef pour décider peuvent "plomber" un projet correctement dimensionné par ailleurs.
Ce qu'il faut faire :
- ne pas sous estimer le coût et la durée du projet : mieux vaut surdimensionner légèrement les besoins en ressources - quitte à réduire légèrement le périmètre du projet - que l'inverse.
- éviter le classique "effet tunnel" (manque d'implication du client ou du service concerné pendant la phase de développement) en animant concrètement le projet.
- ne pas attendre trop longtemps l'implication d'une autre direction potentiellement légitime sur le contenu du projet. Mieux vaut aller au clash que de chercher à tout prix à éviter les conflits directs. Ils éclateront de toute façon tôt ou tard.
4. Faire évoluer le périmètre fonctionnel en cours de route
De nombreux clients sont conscients d'avoir validé des spécifications détaillées mais cela ne les empêche pas de demander des évolutions fonctionnelles avant même la recette de la première version. Résultat : les rustines s'accumulent dans la précipitation jusqu'au moment où il est
préférable de tout remettre à plat.
Ce qu'il faut faire :
- S'en tenir aux contraintes initiales (périmètre fonctionnel, budget, charge, planning) quitte à livrer un projet moins ambitieux mais opérationnel. Petit rappel, un utilisateur utilise 80% de sont temps seulement 20% des fonctions d'un outils informatique.
- Temporiser et planifier à nouveau le projet s'il n'y a pas d'autre solution. Même si cela reste souvent un voeu pieux, il faut conserver un périmètre de développement le plus fixe possible.
Sylvain Bonnet Passemar
--------------------------------------------------------------------
Adresse du blog : https://blogs.mediapart.fr/sp-0/blog
Passionné d'informatique, de nouvelle technologie, et de société de l'information, j'édite ce blog qui traite de sujet de sécurité informatique. Le but de ce blog est de s’adresser auprès d’un public varié : direction, utilisateur, informaticien. C’est pour cela qu’il est hébergé sur un site généraliste. La sécurité, c’est une en premier lieu une organisation, et non un rôle purement technique. J'ai commencé ma carrière dans la presse informatique dans les années 90, puis un long passage très intéressant comme informaticien en salle des marchés et banque d'investissement, puis une administration internationale.