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 !

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

Le , par Arsene Newman

71PARTAGES

3  1 
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 ?

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

Avatar de Aurelien Plazzotta
Membre extrêmement actif https://www.developpez.com
Le 10/03/2014 à 21:28
Peut-être aussi le système de rémunération des chefs de projet les poussent-t-il à prendre et maintenir des décisions absurdes.

J'ai travaillé pour différents chefs de projets qui basaient leur niveau de vie en tablant sur le fait que les primes annuelles et le salaire ne faisaient qu'un.
Ils ne pouvaient donc tolérer l'absence de primes pour l'année suivante. Ils en venaient donc à accepter des échéanciers fantasmagoriques (comprendre irréalisable ), des technologies non maîtrisées ainsi qu'une dette technique à faire pâlir celle du Traité de Maastricht.

Sans oublier le transfert indû des responsabilités qui met à mal la motivation des opérationnels :
"Quand ça marche, jme félicite, quand ça merde, tu t'excuses."

Allez j'imagine que tout le monde a connu ça :
13  0 
Avatar de a028762
Membre confirmé https://www.developpez.com
Le 11/03/2014 à 19:05
Dans ma société, on a décidé de ne plus faire de développement informatique mais de les acheter.
On a donc des produits informatiques incapables de nous aider,
des utilisateurs devenus incapables de définir leurs besoins,
des informaticiens devenus incapables de créer des produits informatiques pertinents.
De toute façon, on a décidé que les MOA ne servaient à rien et coûtaient trop chers.
Du coup, plus besoin de MOE non plus (évidemment) et
on a décider de faire plutôt confiance à ceux qui nous vendent leurs produits.
On attend avec impatience le retour de balancier :-)
10  0 
Avatar de 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
9  0 
Avatar de 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.
7  0 
Avatar de
https://www.developpez.com
Le 11/03/2014 à 17:29
Citation Envoyé par puke502 Voir le message
pour moi c'est l’incompétence qui a tendance a ce généraliser
plus ça va plus moins je rencontre de mecs bons qui savent de quoi ils parlent..

1)si tu es bon, en principe tu es chers mais tu boss vite et bien, dans cette optique tout le monde peut s'y retrouver
2)si tu es mauvais, en principe tu veux aussi être chers que les bons ! mais tu boss lentement (cherche google and co) et tu fais mal ..

bref je sais pas pour vous mais moi je croise énormément de cas d'exemple 2) ... en PME et encore plus dans les grands comptes
+1

Je bosse dans un domaine un peu différent de l'IT (déploiement d'infras de switching/routage) et les plus belles gamelles, je les ai souvent vues pour cause d'incompétence du ou des chefs de projet : manque d'expertise technique, mauvaise communication, chemin critique flou et micro-management mal placé

Il y a un autre phénomène que j'ai vu s'amplifier ces dernières années : les cycles de décision devenant extrêmement longs pour approuver des budgets, même de quelques dizaines de k€, il est plus facile d'avoir 6 enveloppes mensuelles de 8 k€ pour payer un "chef de projet pas très bon" pendant 6 mois à 400€/jour plutôt que de payer un très bon 20 k€ par mois pendant 3 mois pour réaliser le même projet. Ca, je l'ai vu beaucoup de fois...

Steph
7  0 
Avatar de Grom61736
Membre éprouvé https://www.developpez.com
Le 11/03/2014 à 14:06
Malheureusement, comme toujours, ceux qui auraient le plus besoin de savoir comment éviter l'échec d'un projet ne chercheront pas à le savoir.
5  0 
Avatar de Katyucha
Expert confirmé https://www.developpez.com
Le 21/03/2014 à 17:27
Je bosse dans l'administration système, il est TRES rare qu'un CdP vienne nous consulter au début d'un projet ! On claque directement l'application sur des serveurs de Dev, ca monte en intégration et paf en production, ca s'écroule à plus de X utilisateurs.

La plupart des anciens informaticiens était des gens passionnés, qui avait une grande connaissance transverse. Certains avaient fait plusieurs Jobs en informatique avant de prendre des projets. Aujourd'hui, ce n'est plus le cas. Les informaticiens sont dans des cases : développeur X, admin X, ....etc. Plus aucune vision transverse ! Nous ne formons plus de Chefs de Projets. Nous en fabriquons. Erreur monumentale. Les CdP deviennent incompétent car ils n'ont plus aucune vision transverse.
5  0 
Avatar de lilington
Membre chevronné https://www.developpez.com
Le 24/03/2014 à 3:14
au vu de vos deux commentaire katyucha et pmithrandir,
il y a deux responsables a ca (au moins deux). les entreprises et l'educations (universite et ecole superieure).
pour les premiers ils imposes au ecole le programme, genre actuellement on a besoin de programmeur X donc forme nous des programmeurs X
les seconds eux pour pouvoir dire "regarder quand on sort de chez nous on a un job" vont suivre le rythme et former des programmeurs X.
la formation est morte. aujourd'hui peu son reellement pationnes. pour preuve si vous avez des amis etudiants developpeur, proposez leur de developper un truc quelconque qui leur demandera de la recherche et du temps et qui ne leur rapportera rien (ni argent,ni bonne note) ils vous diront qu'ils ont "trop de cours pas vraiment de temps mais c'est interressant hein je vais essayer de m'y mettre".
la plus part n'ont pas la passion.
d'ailleurs quand on cherche un boulot rarement le recruteur cherche a voir si vous etes passionne ce qu'il cherche c'est votre niveau actuelle de competence.
moi je prevere un tres peu competent passionne avec une courbe d'apprentissage enorme qu'un competent qui peut rien apprendre de nouveau.
5  0 
Avatar de azias
Membre éclairé https://www.developpez.com
Le 11/03/2014 à 12:43
Pour moi une bonne source d'échec c'est la disparation du modèle de développement V. Plus précisément le fait que le développement se fasse officiellement avec un modèle en V alors qu'en pratique ce n'est pas du tout le cas: début des développements avant même qu'une spec ne soit faite, la spec qui arrive en plein milieu du développement et qui ne correspond évidemment pas à ce que les développeurs avait compris, prévu et commencé à développer, les specs qui changent quotidiennement parce que les gens qui font les specs "se rendent mieux compte en voyant le résultat", les tests faits à la va vite parce que "y'a pas de modfs très compliquées, pas de risque, on vérifie juste l’affichage"... Tout ça prend arrive à son paroxysme le jour où la "spec finale" arrive enfin... le jour de mise en prod (quand ce n'est pas le lendemain).
4  0 
Avatar de CodeurPlusPlus
En attente de confirmation mail https://www.developpez.com
Le 11/03/2014 à 22:56
Non mais le premier problème vient de la manière dont se font les recrutements. On recrute systématiquement ceux qui se présentent le mieux et qui ont l'air les plus sûrs d'eux. On recrute à la gueule quoi. C'est peut-être une bonne manière de recruter un commercial, mais pas du tout une bonne manière de recruter un programmeur (le terme de "développeur" est ridicule, il ne veut rien dire). Si on recrute les mauvais, les projets foirent, c'est triste mais parfaitement logique.
5  1