Pourquoi les projets IT échouent si souvent ?
Le manque de ressources serait la principale cause, selon une étude

Le , par Arsene Newman, Expert éminent sénior
Innotas, en bonne entreprise américaine de conseils en gestion de projet IT et Cloud, a dévoilé les résultats de son étude sur l'échec des projets IT en entreprise.
Chose étonnante, lors de la dernière année plus 50% des professionnels questionnés avouent l'échec d'un projet IT, mais alors qu'elle est la principale cause? Pour 74% d'entre eux, le manque de ressource serait la cause principale.

Vrai ou faux ? Y a-t-il véritablement manque de ressource ? Manque de chefs de projet IT ? La question a été posée au président de l'entreprise spécialisée dans la recherche d'emploi Dice.com, à savoir Shravan Goli, il révèle alors que le nombre de postes de « chef de projet » qui reste à pourvoir reste à un seuil stable de l'ordre de 3.200 postes libres.

Est-ce que c'est le véritable problème ? Pas tout à fait, ce métier connaît une croissance stable et attire pas mal de monde vu le salaire annuel moyen plus conséquent que pour les autres métiers IT (106.000$ contre seulement 85.000$, aux États-Unis), toutefois avec la croissance rapide et la diversification des domaines d'application de l'IT et l'introduction des méthodes de développement agiles, le rôle d'un chef de projet a évolué et demande par conséquent plus de compétences, allant du management du projet en sa globalité, la motivation des équipes, le maintien d'une bonne communication entre les groupes à la supervision des développeurs et des cycles de développement.

En revanche, pour le président de Innotas Kevin Kern, le manque de ressource ne constitue pas l'unique cause de cet échec, pour lui les entreprises ont tendance à considérer les départements IT comme un fardeau financier et seraient les départements les plus en proie aux coupes budgétaires, or ces derniers devraient être considérés comme une des clés de la réussite d'une entreprise moderne.

De plus la difficulté de mise en œuvre des projets n'est pas prise en valeur lors de la soumission du projet par les cercles de décision, ces derniers préférant se focaliser sur sa valeur ajoutée, ce qui conduit inéluctablement à un échec.

Enfin, autres faits notables qui ressortent à travers cette étude :
  • 64% des professionnels interrogés affirment l'existence d'un bureau de gestion de projet, ce qui n’empêche pas l'existence de carence en terme de gestion des ressources
  • Bénéfices de la réalisation du projet (17%), Établissement des priorités (14%), Budget (13%) et Alignement avec la concurrence (5%) sont les principaux challenges auxquels il faut faire face pour le succès du projet.
  • 94 % des sondés estiment que le succès du projet est d'une importance cruciale pour la réussite de leur entreprise.

Source : Talkincloud.com

Et vous ?

Qu’en pensez-vous ?


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 10/03/2014 à 12:04
Bonjour,

Je suis d'accord avec les deux analyses : d'un cote, on manque de vrais chefs de projets competents, et de l'autre, avec ou sans chef de projet, un projet informatique n'est qu'un centre de cout, bien trop eleve, dans lequel on peut sabrer a loisir.

Combien de projets a-t-on chiffre a X, reellement, et la reponse est apres "bon, a vendu X/3, avec pleins de fonctionalites en plus, debrouillez-vous" ?

Apres, les entreprises ne savent pas chercher un chef de projet : soit elles prennent un bon developpeur pour le recompenser, et ne le forment surtout pas a son nouveau poste, soit elles cherchent un mouton noir et jaune a 6 pattes agiles, et trouvent que tous les candidats ont vraiment de pietres profils.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 10/03/2014 à 14:13
Voici les quelques causes que j'ai identifié sur les échecs des projets IT :
* des projets sous vendu (chiffré X et vendu X/3 comme dit par gangsoleil)
* Réduction des coûts au max avec une équipe réduite, 1 ou 0 développeur expérimenté et x stagiaires (sinon, ce n'est pas drôle)
* Un mauvais cadrage métier (c'est dingue le nombre de fois où j'ai pu constater qu'il a été vendu une usine à gaz d'une rare complexité alors que le besoin métier réel était ridicule et minime )

Le 3ième point est souvent la cause qui revient le plus souvent.
Souvent, les clients et/ou les équipes métiers ne sont pas assez investis dans le développement des CDC.
L'informatique est souvent considéré, à tort, comme une "boîte noire" obscure auquel ils ne comprennent rien (et ne veulent pas faire l'effort de comprendre) et nous donne le minimum d'info pour qu'on se débrouille "comme on pense que ça devrait"
Au final, on obtient un programme qui ne convient pas et qui du coup, n'est pas utilisé

Les choses changent pas mal avec le développement des méthodologies agiles mais ça prend du temps
Avatar de benjani13 benjani13 - Membre expérimenté https://www.developpez.com
le 10/03/2014 à 15:29
Citation Envoyé par Saverok  Voir le message
* Réduction des coûts au max avec une équipe réduite, 1 ou 0 développeur expérimenté et x stagiaires (sinon, ce n'est pas drôle)

J'ai connu ça l'année dernière, nous étions uniquement 5 apprentis sur un projet (dev SAP). En plus c'était notre tout premier projet après notre embauche, et nous n'avions pas été formé à SAP.
C'était google toute la journée

Je rajoute que quelque mois après un des apprentis a été envoyé chez un client en tant que formateur SAP
Avatar de Aurelien Plazzotta Aurelien Plazzotta - Membre éclairé https://www.developpez.com
le 10/03/2014 à 15:41
L'article est très révélateur d'un cercle vicieux qui se maintient, et pour longtemps.

94% des sondés se font mousser en assurant que le département IT est d'une importance cruciale, mais seulement 14% font preuve de sens commun en établissant des priorités (résultat: l'expression de besoins fait office de cahier des charges et 45% des fonctionnalités développées ne sont jamais utilisées, source Choisir l'agilité de M.BOISVERT et S.TRUDEL).
La situation n'est pas près de changer.

D'ailleurs, dans les projets agiles, il n'y a pas de chef de projet, il n'y a que des facilitateurs.

Depuis l'ère post-Google, la Recherche et Développement est devenu l'un des rares départements au sein d'une entreprise à produire encore de la valeur ajoutée. Il est donc logique (connaissant la nature intrinsèque de l'Homme), que les autres départements (qui eux ont des décideurs siégeant au conseil d'administration), justifient leur contrat de travail en empêchant le service IT de sortir de l'ombre.

Je reconnais néanmoins que mon jugement est biaisé car je n'ai jamais travaillé dans une petite entreprise.
Avatar de super_navide super_navide - Provisoirement toléré https://www.developpez.com
le 10/03/2014 à 15:53
Les echecs viennent je suis sûre du fait que le métier de base dans l'informatique qui celui de concepteur développeur est telement peux valorisé qu'il implique forcément des echecs par manque de motivation et d'intéret.
Avatar de Albinre Albinre - Membre à l'essai https://www.developpez.com
le 10/03/2014 à 16:21
Il y a le manque de ressources, mais le point à noter c’est que le marché des IT est presque saturé et que les projets qui sortent du lot se font rares…, ce qui fait que le besoin n’est pas déclenché chez le consommateur ….
Avatar de Johnny P. Johnny P. - Membre actif https://www.developpez.com
le 10/03/2014 à 16:21
Les echecs viennent je suis sûre du fait que le métier de base dans l'informatique qui celui de concepteur développeur est telement peux valorisé qu'il implique forcément des echecs par manque de motivation et d'intéret.

Entre autre mais je crois aussi que tous les projets ne sont pas destinés à réussir faut voir au cas par cas , à partir du moment où un projet est lancé c'est une expérience jamais tentée donc un risque.

Je pense plutôt que les projets qui réussissent le mieux ce sont ceux qui sont réalistes tant sur le plan technique que fonctionnel ce qui n'est pas toujours le cas trop souvent le code devient complexe , le développeur/programmeur est prit pour un magicien ou son avis ne compte tout compte fait pas lors des choix voir rarement.

Ce qui est sûre c'est qu'un développeur n'a presque aucun pouvoir sur un projet même si tu fonces sur quelque chose où tu sais que (techniquement) ça va pas fonctionner mais que ton chef lui est illuminé qu'il faut faire ainsi.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 10/03/2014 à 17:04
Gangsoleil a toujours raison, et Saverok a bien complété : tant qu'on aura des décideurs qui
(1) baseront tant les objectifs que les moyens sur des fantasmes
(2) refuseront d'impliquer des sachants métier dans le projet

mais aussi de développeurs qui

(3) partiront bille en tête en sachant qu'ils vont se planter, mais en espérant quand même s'en sortir.

on aura beaucoup de casse.

Le point (1) est lié à la jeunesse de nôtre discipline, et devrait se réduire avec les siècles. Le point (2) devrait être plus facile à corriger, mais à condition de faire passer l'information au bon endroit : les sources d'information des décideurs, pas celles des informaticiens de métier. Le point (3) me parait incorrigible : c'est la nature humaine.
Avatar de marc.collin marc.collin - Membre confirmé https://www.developpez.com
le 10/03/2014 à 17:19
Rien de bien nouveau, le Standish Group via son Chaos report obtient des chiffes similaires.

De nombreuse méthodlogie et bonne pratique existe: PRINCE2, PMI, ITIL, Six Sigma...
Elles ont déjà fait leur preuve, de nombreux ouvrages sortent à chaque année.

Un bon livre par exemple
INFORMATION TECHNOLOGY PROJECT MANAGEMENT

Le chef de projet doit gérer une panoplie de domaine dont les risques, communication, échéancier, plan d'affaire, budget...
Ce n'est pas tous le monde qui a les compétences.

Il y a beaucoup trop de décideur pressé qui prenne des décisions critiques après avoir lu un titre d'un magasin.
Des mauvaises décisions, ce n'est pas ça qui manque en informatique. J'en ai vu énormément qui rejetait la faute
d'échec sur les autres alors qu'au final, c'est lui le chef.

Une bonne communication, implication des utilisateurs font partie des critères pour réussir un projet.
La technologie est rarement l'écher d'un projet.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 10/03/2014 à 17:22
Citation Envoyé par Johnny P.  Voir le message
Je pense plutôt que les projets qui réussissent le mieux ce sont ceux qui sont réalistes tant sur le plan technique que fonctionnel ce qui n'est pas toujours le cas trop souvent le code devient complexe , le développeur/programmeur est prit pour un magicien ou son avis ne compte tout compte fait pas lors des choix voir rarement.

Je ne partage pas ton avis.
Les clients n'ont pas assez d'argent pour investir dans des trucs au hasard.
Et puis, la nouveauté n'est pas forcément au rdv.
J'ai connu des projets qui n'avaient rien d'innovant (et même plutôt archaïque dans le concept) se vautrer lamentablement.

Je pense que c'est souvent une mauvaise préparation qui est la cause de l'échec du projet.
C'est un peu comme si une fois que le projet a été approuvé en CA, il fallait tout de suite le mettre en route et avoir le plus rapidement quelque chose à montrer.
Du coup, on a juste une expression de besoin mais rien qui ne ressemble à un CDC et encore moins à un SFG mais les dev eux, débutent...
Et là, les développeurs composent presque à l'aveugle et les multiples ajustement entraînent de la complexité (et avec des développeurs débutant, c'est encore mieux...).
Au final, on obtient quelque chose d'ultra bugué qui ne répond pas aux besoins
Offres d'emploi IT
Architecte systèmes études & scientifiques H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Chef projet big data - pse flotte H/F
Safran - Ile de France - Évry (91090)
Responsable transverse - engagement métiers H/F
Safran - Ile de France - Corbeil-Essonnes (91100)

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