Mardi 12 décembre 2017
NASDAQ : 0.0 0   nasdaq0 %
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 (suite)

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

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.

 

5. Faire confiance à une équipe junior

Malheureusement, la direction informatique peut rarement disposer de l'équipe projet dont elle rêve. De nombreux prestataires et directions informatiques marient juniors et seniors dans leurs équipes pour gagner en rentabilité et donc diminuer le coût du projet. "Le problème c'est qu'il faut former les juniors. Ce n'est pas très grave pour un développeur, en revanche lorsqu'il s'agit du chef de projet, le risque de dérapage est très important", souligne Franck Laudet.

Ce qu'il faut faire :
- Lotir et suivre avec beaucoup de rigueur les développements, surtout quand ils sont externalisés ou sous-traités en off shore ou near shore. "Pour les projets importants on peut par exemple livrer des versions intermédiaires", conseille Stéphane Bordage.
- Imposer au prestataire ou aux clients interne un budget suffisant pour disposer d'un chef de projet expérimenté qui saura éviter les nombreux pièges qui l'attendent.

6. Ajouter des intervenants en cours de projet

Face à une équipe trop "junior", sous dimensionnée ou manquant d'expertise sur un point clé du projet, la tentation est souvent grande de faire intervenir de nouveaux prestataires en cours de route ou des utilisateurs lorsque le cahier des charges fonctionnel manque de précision. Si elle n'est pas impossible, cette démarche doit être pratiquée avec beaucoup de précaution. "Nous voyons souvent un responsable absent au début et qui s'implique à mesure que le projet prend corps. Le problème dans ce cas, c'est que les décisions deviennent bicéphales, ce qui n'est jamais bon en conduite de projet", estime Stéphane Bordage.

Ce qu'il faut faire :
Ne pas oublier de définir l'organisation du projet et la valider avec le prestataire au cours de la réunion de lancement. En général, l'organisation du projet est fixée par le comité de pilotage du projet constitué de membres de la maîtrise d'ouvrage (MOA).


7. S'appuyer sur une méthodologie trop lourde et trop contraignante

Très à la mode ces derniers temps, les méthodologies ITIL et CMMI sont pertinentes à l'échelle du système d'information de l'entreprise et sur les très gros projets. Mais pour les projets plus modestes (10 à 250 jours de développement), "CMMI rajoute vite 10 à 30 % de charge supplémentaire, ce que nos clients ne sont pas prêts à payer", estime explique Stéphane Bordage.

Ce qu'il faut faire :
- Adapter la méthodologie à la nature, l'enjeu et la taille du projet. C'est ce que ne font pas les informaticiens et les publicitaires sur le web : chacun applique une méthode sans se poser de question alors que le rôle du chef de projet est justement d'adapter la méthode.


8. Ne pas tenir compte de l'outil qui permettra d'implémenter le projet

La conception fonctionnelle sera inévitablement influencée par le logiciel ou les technologies permettant de réaliser le projet. "Nous avions sélectionné trop rapidement un outil nous permettant de réaliser une animation sur écran tactile. Si le projet n'a nécessité que 15 jours, nous ne pouvions plus le faire évoluer à cause de contraintes techniques inhérentes à l'outil", illustre Serge Cadenat. Lorsque le projet doit à tout prix évoluer, "on doit souvent "tordre" l'outil pour se conformer à ce qui a été validé, ce qui est très chronophage", constate Stéphane Bordage.

Ce qu'il faut faire :
- Envisager les évolutions possibles de l'application avant de choisir la technologie ou le progiciel sur lesquels reposera le projet.
- Tenir compte de l'outil lors de la formulation des spécifications détaillées (règles de gestion, vocabulaire métier, etc.).


9. S'appuyer sur des technologies trop récentes


RIA, web 2.0, Flex, Silverlight, API web publiques : rarement dans l'histoire de l'informatique les DSI auront eu autant d'options techniques à leur disposition pour réaliser un projet. Très récentes pour la plupart, mais apportant de vrais progrès en termes d'ergonomie, de facilité de maintenance et de rapidité de développement, "ces technologies ne sont malheureusement pas toujours bien maîtrisées par les prestataires", estime Franck Laudet. L'entreprise supporte alors un risque important et finance indirectement la formation des équipes du prestataire, au prix d'un dérapage à la fois sur les coûts et les délais. D'autre part, "un investissement important empêche souvent toute remise en cause de l'outil ou de la technologie qu'il faut rentabiliser (justifier?) à tout prix", rappelle Serge Cadenat.

Ce qu'il faut faire :
- Valider sérieusement les références du prestataire en discutant directement avec le chef de projet de l'entreprise.
- Demander des références de projets réalisés avec les technologies préconisées.


10. Définir une architecture technique monolithique


Pour gagner du temps, la tentation est grande de choisir un progiciel parfaitement adapté à son cahier des charges initial, quitte à ce qu'il soit difficilement extensible. "C'est une erreur car, quelle que soit sa nature, un projet évolue sans cesse", explique Serge Cadenat.

Ce qu'il faut faire :
- S'appuyer sur une architecture modulaire, c'est-à-dire un noyau applicatif pouvant être enrichi fonctionnellement par des modules applicatifs et des extensions.
- Utiliser des technologies très répandues pour s'assurer qu'il sera toujours possible de faire évoluer les développements à un coût raisonnable.

Lire la première partie 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