Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Michael Guilloux

35PARTAGES

4  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 22/04/2015 à 12:48
Monsieur est, pour le moins, un enfonceur de portes ouvertes.
12  0 
Avatar de transgohan
Expert éminent 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...
12  0 
Avatar de 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.
5  0 
Avatar de 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.
5  0 
Avatar de 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.
5  1 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 30/04/2015 à 13:56
Citation Envoyé par Joratois Voir le message
Et qu'une fois les specs bien définies, on s'y tienne !
Autrement dit, impossible de changer d'avis ou de rectifier une trajectoire ????

Sur un mini projet de quelques semaines, ça va
Mais que fait on sur un projet de plusieurs mois ?
Que se passe t'il s'il y a des cas non prévus dans la spec ?

Il est indispensable d'éviter les effets tunnels car c'est le meilleurs moyen de "perdre" les utilisateurs et d'avoir une levée de boucliers lors de la livraison
Il est indispensable d'impliquer les utilisateurs que se soit à la qualif du besoin, à la conception, aux dev et à la recette
C'est ainsi qu'on les implique et qu'on obtient leur adhésion

Tu auras beau faire la plus merveilleuse des appli sur le plan IT, si les utilisateurs n'en veulent pas, elle finira dans un carton et ça sera un échec retentissant
Bien pire qu'une appli bugguée
4  0 
Avatar de 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.
3  0 
Avatar de 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.
3  0 
Avatar de alksddfh
Membre à l'essai https://www.developpez.com
Le 26/04/2015 à 6:06
Citation Envoyé par transgohan Voir le message
Pourquoi cela serais-ce moins irresponsable pour une grande société ?
Dans une petite structure 3 ou 6 mois de développements à mettre à la poubelle ça peut être fatal. Une grosse société a certainement plus de budget pour se sortir de ce genre de situation. Aussi une grosse société peut posséder de haut niveaux de hiérarchie et il est plus 'normal' que la toute haute direction ne soie pas au courant de l'évolution du projet au jours le jour.
3  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 30/04/2015 à 14:55
Tu veux parler de "Accueillez positivement les changements de besoins, même tard dans le projet." (2ème principe - http://agilemanifesto.org/iso/fr/principles.html)

Il faudrait alors parler des besoins réels à des utilisateurs tout au long du développement de ton projet pour voir s'ils évoluent.
Et puis, ça voudrait dire avoir du feed-back de leur part sur ce que tu fais et donc leur proposer régulièrement une "version de démo".
Mais qui dit proposer une telle version, voudrait dire d'avoir régulièrement un produit qui marche, qui est fonctionnel, qui est testé ...

Attention, on est à deux doigts de basculer dans le monde de l'Agilité
3  0