Comment garantir le succès d'un projet IT :
Top 5 des raisons pour lesquelles les projets informatiques échouent

Le , par Michael Guilloux, Chroniqueur Actualités
Il est plus facile de démarrer un projet informatique, mais garantir son succès est une chose moins évidente. Pour réussir, un projet doit se plier à des contraintes de coût, de délai et de respect des exigences définies par le cahier de charges. Dans la pratique, il est difficile de voir un projet respecter ces 3 critères, et les meilleurs projets sont ceux qui arrivent à terme avec un écart relativement faible par rapport à ces critères.

Plusieurs études menées sur la réussite des projets informatiques montrent en effet que dans la majorité des cas, les projets aboutissent avec un non-respect des charges ou des délais. On note également que parfois, plus de 20% des projets sont abandonnés.

Les raisons qui justifient ces taux d’échec sont multiples et peuvent dépendre des ressources financières de l’entreprise, de l’implication des employés, des compétences déployées sur le projet et bien d’autres.

Partho Bhattacharya, président d’Invenio Business Solutions a expliqué les 5 principales raisons pour lesquelles les projets IT échouent selon sa propre expérience au sein de son entreprise. Invenio Business Solutions un Gold Partner de SAP qui fournit des solutions, des services et un support SAP aux entreprises.

Selon Partho, le principal facteur de succès ou d’échec d’un projet est l’implication de la haute direction. Il fait partie de ceux qui partagent l’avis selon lequel « il n’y a pas de projets informatiques, mais seulement des projets d’entreprise ». autrement dit, les projets IT doivent impliquer et rassembler l’entreprise dans son ensemble et pas seulement le service informatique. La haute direction qui doit avoir un intérêt particulier dans la réussite du projet doit veiller à cela.

Il est donc important, avant tout, de faire une cartographie des personnes qui sont impliquées dans le processus et de s’assurer qu’elles en fassent partie depuis le début et que leurs besoins et fonctions ont bien été considérés.

Une autre raison qui mine les projets IT serait la mauvaise planification. Partho note que très souvent, les calendriers manquent de réalisme. Les responsables doivent définir des délais plus réalistes dès le départ et éviter de se précipiter dans les projets.

Il explique encore qu’un projet a des chances d’échouer si les données et l’interface avec le système sont ignorées dès le départ. Les données des systèmes en place sont souvent incohérentes et incomplètes et rendent parfois le système inutilisable. Ce problème doit être avant tout traité par le nettoyage des données qui est susceptible de prendre beaucoup de temps dans la réalisation du projet. Les interfaces, qui constituent les points de contact avec le système doivent être également testées, car une interface défectueuse peut mettre en mal une bonne implémentation du système.

Un autre facteur d’échec ou de succès, non des moindres, est la gestion du projet, les compétences et expériences. Partho explique qu’un de chef de projet approprié et le soutien de l’équipe PMO sont primordiaux pour le succès du projet. Il faut également éviter trop de gestionnaires au risque de créer des conflits et priorités contradictoires. Ces derniers doivent encore avoir de très bonnes compétences, être capables de réunir la bonne équipe de personnes qualifiées et également être en mesure de les motiver et inspirer même quand la pression monte.

Le président d’Invenio Business Solutions note par-dessus tout qu’on doit maintenir le projet réel. Par cela, il explique que lors de la planification et du déploiement, certaines attentes autour de ce qui doit être livré, quand, par qui et pourquoi, sont irréalistes. Il y a des exigences confuses ou changeantes tout au long du processus. Partho pense qu’elles doivent plutôt être fixées et les objectifs réévalués au cours du projet pour éviter les surprises. Pour cela, le choix du partenaire est vraiment crucial. Ce dernier doit être en mesure d’accompagner l’entreprise dans tout le processus afin d’assurer le succès du projet.

Source

Et vous ?

Qu’en pensez-vous ?

Quels sont les facteurs qui pourraient compromettre la réussite d’un projet informatique ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de gangsoleil gangsoleil - Modérateur https://www.developpez.com
le 22/04/2015 à 12:48
Monsieur est, pour le moins, un enfonceur de portes ouvertes.
Avatar de transgohan transgohan - Expert confirmé https://www.developpez.com
le 22/04/2015 à 12:50
Citation Envoyé par Michael Guilloux  Voir le message
Une autre raison qui mine les projets IT serait la mauvaise planification. Partho note que très souvent, les calendriers manquent de réalisme. Les responsables doivent définir des délais plus réalistes dès le départ et éviter de se précipiter dans les projets.

Client : Une réduction de xxxM€ ? Uniquement si vous nous livrez pour hier.
Commercial : Marché conclu !


Faut pas penser qu'aux responsables, les commerciaux sont souvent en première ligne pour ce genre de c*nneries...
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 22/04/2015 à 12:51
Citation Envoyé par Michael Guilloux  Voir le message
Qu’en pensez-vous ?

je pense que plus d'un projet aurait été un succès logiciel si la direction avait moins mis son nez dedans.

https://youtu.be/BKorP55Aqvg

Citation Envoyé par Michael Guilloux  Voir le message
Quels sont les facteurs qui pourraient compromettre la réussite d’un projet informatique ?

tout dépend du point de vue. Pour le développeur, on peux très bien mesurer le succès d'un projet au nombre de zéros sur la facture, du point de vue client c'est plutôt l'inverse

Après, dire que quand tout le monde y mets du siens, le projet a plus de change d'aboutir, faut pas être président de quoi que ce soit pour s'en rendre compte.
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 22/04/2015 à 12:59
le coup des specs changeantes c'est la principale raison d’échec
et le plus souvent c'est à cause du commercial qui n'est pas fichus de situer le besoin
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 22/04/2015 à 15:11
Citation Envoyé par TiranusKBX  Voir le message
le coup des specs changeantes c'est la principale raison d’échec
et le plus souvent c'est à cause du commercial qui n'est pas fichus de situer le besoin

ce n'est pas son rôle.
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 22/04/2015 à 15:36
c'est lui qui vend le service il est censé savoir si c'est possible ou non à faire
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 22/04/2015 à 15:39
Citation Envoyé par Paul TOTH  Voir le message
je pense que plus d'un projet aurait été un succès logiciel si la direction avait moins mis son nez dedans.
(.../...)

Mon expérience personnelle va dans ce sens-là. La meilleure direction, c'est celle qui dit "bon, c'est important, demerdez-vous pour que ça marche", et qui vient vérifier tous les 3 mois qu'on avance.

Après, évidemment, je suis un échantillon limité. Mais quelques exemples vécus :

_Un remplacement complet de SI, en passant du COBOL à JAVA, parce que c'est moderne. 100M$ foutus à la benne parce que les traitements comptables de fin d'année mettent une semaine à tourner. Sur 5% de la clientèle.
_Un remplacement complet de gestion des référentiels tiers. Projet à 60 personnes et prévu sur 18 mois. Les specs ont deux ans d'âge, et sont devenues fausses. 6 ans de retard parce que le vice-président(coté client) qui a signé les specs refuse de se dédire. Soit ça marche, mais ce n'est pas conforme, soit c'est conforme, mais ça ne marche pas. Et un redémarrage sur de nouvelles bases au bout de 6 ans.
_Une refonte complète des courriers envoyés au client. La direction fait savoir que c'est prioritaire. Les prestataires(moi et un quasi-débutant) sommes lâchés avec pour seule consigne de "faire comme l'existant, mais en lisible et maintenable". Au milieu du projet, je m'aperçois que j'ai fait fausse route. Je ne sais pas faire de tests unitaires. "Je dois créer un comparateur avec l'ancien système, pour vérifier que tout est bon. Y'en a pour 4-5 semaines, facile". Réponse : "gloups, bon, ben si il le faut... La direction insiste sur la date de livraison, tiens-en compte". Il m'a fallu 6 semaines, mais à la fin, les tests unitaires étaient aussi terminés. Sur 170 jours de planifiés, un total de 172 de consommés. Livré le jour prévu. Zéro anomalies lors de la mise en prod, un cout de maintenance divisé par deux par rapport à l'ancien système.
_Plus anecdotique,
"_el-slapper on a un problème. Il y a un programme qu'on a oublié de faire. On avait budgetisé 10 jours. Tu en as deux."
"_C'est quoi?"
"_Passer les 18 flux du nouveau format vers l'ancien format. C'est pour les DOMTOM - leur SI est indépendant. Tiens, regarde les specs."
"_mmmmh, les 18 flux se ressemblent beaucoup..."
"_Bon, si on a juste Bourse France, Bourse étrangère, et OPCVM, on fera avec, les 15 autres peuvent attendre."
"_Vu les specs, faire 3 flux en 2 jours, je n'y arriverais pas. Mais faire une moulinette qui me fait les 18 en dynamique, je peux faire.
"_Glps....Euh, tu est sur de ton coup?"
"_on y arrivera pas autrement"

Et ça a marché. Si il avait insisté pour que je fasse les flux un par un, j'y serais encore. En plus, vu que les specs elles aussi avaient été faites en catastrophe(mais avec une structure impeccable, ce qui m'a sauvé), elles étaient pleines d'erreurs, et il valait mieux que j'ai à faire les corrections à un seul endroit, plutôt qu'à 18...

Après, un bon chef sait donner aux gens les moyens de bosser. J'ai connu une DP, par ailleurs très moyenne(elle ne connaissait que COBOL, et ne comprenait pas pourquoi les JAVAistes avaient besoin d'un accès à internet, genre "vous ne connaissez pas votre langage"), qui a remué ciel et terre pour nous avoir des environnements de tests fonctionnels. On a perdu 3 semaines, mais sans elle, c'était 3 mois. Sur un projet de 6 mois. C'est le bon niveau d'intervention. Apprendre aux JAVAistes comment programmer sans internet, c'est idiot. C'est beaucoup trop terre-à-terre pour quelqu'un à son niveau(et, de toutes façons, c'est idiot). Fouetter l'équipe qui avait vraqué les environnements, par contre, c'était son job.
Avatar de lpa lpa - Membre du Club https://www.developpez.com
le 22/04/2015 à 15:44
Quels sont les facteurs qui pourraient compromettre la réussite d’un projet informatique ?

- Comme dit plus haut que le commercial ne vende pas des projets infaisable en terme de délais ...

- Comme l’analyse et les spécification en amont sont bâclées voir inexistante
Avatar de Traroth2 Traroth2 - Membre chevronné https://www.developpez.com
le 22/04/2015 à 15:48
Citation Envoyé par transgohan  Voir le message
Client : Une réduction de xxxM€ ? Uniquement si vous nous livrez pour hier.
Commercial : Marché conclu !


Faut pas penser qu'aux responsables, les commerciaux sont souvent en première ligne pour ce genre de c*nneries...

D'où la notion ridicule de "rétro-planning". Un rétro-planning, c'est quand on t'indique d'entrée quel délai tu as et qu'on te demande de faire un truc qui ressemble à un planning et qui doit tomber pile-poil dans ce délai. Sachant que de base, une des missions les plus importantes du planning est de déterminer le délai, et que donc, là, on a fixé un délai sans avoir de planning (au pif, quoi), ça veut simplement dire qu'on a envie que le gars qui est chargé de faire le fameux "rétro-planning" partage la responsabilité de l'échec. Ou alors qu'il fouette son équipe pour qu'ils travaillent nuits et jours.

Personnellement, je veux bien faire des projets en mode "best effort", c'est à dire avec un délai qui ne me parait pas réaliste mais j'essaye quand même de faire au mieux, mais je refuse de perdre mon temps dans ce genre d'exercice fumeux dont le but n'est que de me manipuler. Si je ne décide pas du délai, que le gars qui a décidé porte la responsabilité si ce délai n'est pas respecté. Et si on insiste pour que je fasse un planning, je ne me sens pas obligé de tomber comme par hasard sur la deadline qu'on a décidé sans moi.
Avatar de landry161 landry161 - Membre éprouvé https://www.developpez.com
le 22/04/2015 à 16:26
Citation Envoyé par Traroth2  Voir le message
D'où la notion ridicule de "rétro-planning". Un rétro-planning, c'est quand on t'indique d'entrée quel délai tu as et qu'on te demande de faire un truc qui ressemble à un planning et qui doit tomber pile-poil dans ce délai. Sachant que de base, une des missions les plus importantes du planning est de déterminer le délai, et que donc, là, on a fixé un délai sans avoir de planning

Et surtout sans même avoir une idée de la complexité du travail.
C'est bien beau de donner les délais de façon précipitée aux clients surtout quand on n'a pas conscience des contraintes auxquelles peuvent être confrontés l'équipe de développement.
Offres d'emploi IT
Ingénieur système de commande de vol H/F
Safran - Ile de France - Massy (91300)
Responsable de lot / architecte fpga H/F
Safran - Ile de France - Éragny (95610)
Ingénieur produit (Landing gear) H/F
Safran - Ile de France - MASSY Hussenot

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil