Vendredi 20 octobre 2017
NASDAQ : 6605.0669 19.1533   nasdaq0.29 %
RECHERCHE
OK
 
NEWSLETTER
newsletter
Abonnez-vous gratuitement
à notre newsletter
hebdomadaire - Cliquez ICI
Indexel
  • DOSSIERS
  • PRATIQUE
pub Publicité
 

MANAGEMENT

Projets informatiques : les dix erreurs à ne pas commettre

Imprimer Envoyer à un ami Contacter la rédaction
Par Alain Bastide le 17/10/2007 - indexel.net
 

Un tiers des projets informatiques dérapent au niveau des délais comme des coûts. Trois experts nous révèlent les principaux écueils qu'ils rencontrent au quotidien et comment les éviter.

 

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", constate Stéphane Bordage (photo), cofondateur de Breek, une SSII qui accompagne les maîtrises d'ouvrage (AMOA). "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", énumère-t-il. Un constat que partagent Franck Laudet, responsable du système d'information de Cogedim et Serge Cadenat, responsable NTIC dans une grande institution. Ces trois spécialistes détaillent les dix erreurs à ne pas commettre et nous donnent des pistes pour les éviter. Tour d'horizon.

1. Mal définir son besoin

La première pierre d'achoppement des projets informatiques est souvent une mauvaise définition du projet. "Nous répondons souvent à 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 !", constate Stéphane Bordage. Pire, selon lui, certaines 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", estime Franck Laudet. Pour lui, 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", explique-t-il.

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", rappelle Franck Laudet.
- 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", explique Serge Cadenat. 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", note Franck Laudet.

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 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", conseille Serge Cadenat.

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", constate Stéphane Bordage. 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.
- 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", conseille Franck Laudet.

Lire la suite de l'article 

LIRE AUSSI
 
Partager :
LIRE AUSSI
 
pub Publicité

CloudStack by IkoulaCloudStack by Ikoula

Cloud Computing : Atouts et freins, acteurs du marché, conseils et témoignages