Discussion :

[Michael Guilloux]

IBM poursuivi par l’État de Pennsylvanie pour l’échec d’un projet
en partie en raison d'un turnover fréquent de son personnel

Le gouverneur de la Pennsylvanie Tom Wolf et son administration ont porté plainte contre IBM, évoquant les échecs du géant de la technologie dans la mise en place d’un système informatique de gestion des indemnités de chômage au sein de l’État.

Le projet de système de modernisation de l’indemnisation de chômage (UCMS) a été attribué à IBM dans un contrat à prix fixe de 110 millions de dollars et avec une date de livraison prévue pour février 2010. L’expiration du contrat lui-même a été fixée pour l’année 2013. Mais en fin de compte, c’est un projet qui n’a jamais été livré alors qu’il a engendré des coûts de développement supplémentaires. Le Département du Travail et de l’Industrie (DLI) de la Pennsylvanie, à qui le système était destiné, a également continué à supporter les coûts élevés liés à l’utilisation de son système existant, vieux de plus de 50 ans et qui utilise un logiciel qui n’était plus enseigné.

« En somme, les contribuables de la Pennsylvanie ont payé à IBM près de 170 millions de dollars pour ce qui était censé être un système complet, intégré et moderne qu'ils n'ont jamais obtenu », a déclaré le gouverneur Wolf. « Au lieu de cela, le Département du Travail et de l'Industrie (DLI) a été obligé de continuer à prendre en charge une grande partie de ses activités du programme UC (indemnités de chômage) grâce à une collection de systèmes legacy, vieillissants et coûteux, engendrant des dizaines de millions de dollars en coûts de serveur, de support et de maintenance ». Mais comment sommes-nous arrivés à la non-livraison du projet ?

Comme les délais étaient repoussés et les coûts (censés être fixes) augmentaient, en 2013, une évaluation indépendante du projet d'IBM a été commanditée par l’État de Pennsylvanie. Dans le rapport de l'Université Carnegie Mellon, qui a examiné le projet, il a été recommandé au DLI de ne pas poursuivre le projet en raison du risque élevé d'échec. Le rapport a en effet identifié de nombreux problèmes avec la conception et la mise en œuvre du système.

« Étant donné que le système d'IBM présentait des risques inacceptables et ne serait pas fiable, le DLI a permis au contrat UCMS de prendre fin à sa date d'expiration du 28 septembre 2013. À ce moment-là, le projet UCMS avait 45 mois de retard et 60 millions de dollars de plus que le budget », est-il indiqué sur le site officiel de l'État de Pennsylvanie.

Au nom du Département du Travail et de l'Industrie, l’État de Pennsylvanie porte donc plainte contre IBM pour violation de contrat, fausses déclarations, entre autres. « IBM a manqué à plusieurs reprises d'honorer ses engagements et pris des décisions qui ont entravé le bon achèvement du projet », stipule la plainte. À propos de ces décisions ayant entravé l’achèvement du projet, on note, par exemple, le turnover et la réaffectation de personnel clé d'IBM affecté sur le projet. IBM avait pourtant l'obligation de veiller à ce que tous les éléments du projet soient bien coordonnés et exécutés avec compétence et à temps, estime l’État de Pennsylvanie.

Outre le fait qu’IBM n’a pas respecté les délais et les coûts, la plainte stipule que l’offre a été attribuée au géant de la technologie, en raison de fausses déclarations. IBM aurait affirmé être le seul fournisseur avec le type de bases de données propriétaires capable de fournir un système informatique totalement intégré. La plainte stipule également que lorsqu’IBM a présenté sa soumission à l’appel d’offres, la firme s'est vendue comme ayant travaillé avec succès sur des projets similaires en Utah, en Louisiane et à New York.

Avec l’échec d’IBM, le Département du Travail et de l'Industrie de Pennsylvanie fait savoir qu’à partir d’un certain moment, il ne pouvait plus facturer correctement aux employeurs leurs contributions au système d’indemnisation des chômeurs pendant plus d'un an. Au vu de tout ce qui précède, il demande donc des dommages et intérêts non spécifiés.

IBM, de son côté, a déclaré que les allégations de l’État de Pennsylvanie sont sans fondement, et que la société est prête à se défendre « vigoureusement ». Il faut également savoir qu’en 2013, où le contrat a pris fin, un porte-parole d'IBM a expliqué que c'est l'État qui était le fautif, affirmant que « dans les implémentations de technologies de l’information complexes, il y a une responsabilité des deux côtés pour la performance du système et la prestation des services ».

Sources : Associated Press, Communiqué de presse de l’État de Pennsylvanie, Fortune

Et vous ?

Qu’en pensez-vous ?
Avez-vous déjà abandonné le projet d'un client ? Dans la plupart des cas, qui étaient les fautifs ?
Qu’est-ce qui entraîne en général l’échec d’un projet IT ?

Voir aussi :

Fin du télétravail chez IBM ? Big Blue voudrait contraindre ses employés travaillant à distance à rejoindre ses sites ou quitter l'entreprise

[marsupial]

Imaginez qu'il y a 50 ans le code propriétaire n'existait pas donc qu'IBM dans le cas présent dispose de toutes les spécifications pour migrer le système et n'y arrive pas.
Dans le cas de Louvois, s'agissant d'une application classée confidentielle dimensionnée pour un matériel n'existant plus, cela fait aussi près de 10 ans que Sopra-Steria en voit de toutes le couleurs pour l'adapter. Mais là aucune spécification disponible.
J'attends dans 5-10 ans, lorsque le quantique sera suffisamment démocratisé pour servir de serveur par défaut, si tous les génies de ces 30 dernières années vont livrer leur code source propriétaire Windows pour adapter leurs applications.
J'imagine le cas où les ressources ne sont plus disponibles comme pour le cas d'IBM avec l'Etat de Pennsylvanie ce que cela va donner.
Et Microsoft lui même va se faire honnir parce que Windows est dimensionné pour fonctionner sur du x86 et ne porte pas plus que MS Office sur ARM : fiasco total.
Il faut bien comprendre qu'IBM va commercialiser avant la fin de l'année une offre cloud de calcul quantique. Et il ne sera pas le seul. Nous sommes aux portes d'une révolution et gare aux retardataires qui n'arriveront pas à s'adapter. Ca va être la curée.

[Mat.M]

Le gouverneur de la Pennsylvanie Tom Wolf et son administration ont porté plainte contre IBM, évoquant les échecs du géant de la technologie dans la mise en place d’un système informatique de gestion des indemnités de chômage au sein de l’État.

houlala chuut malheureux faut pas que ça se sache surtout en France
échec de la mise en place d'un SI de gestion çe ne vous rapelle rien de certains projets pour des administrations françaises ? ( par exemple la paie des militaires un fiasco de plus de 200millions d'euros )

[Mat.M]

IDans le cas de Louvois, s'agissant d'une application classée confidentielle dimensionnée pour un matériel n'existant plus, cela fait aussi près de 10 ans que Sopra-Steria en voit de toutes le couleurs pour l'adapter. Mais là aucune spécification disponible.
J'attends dans 5-10 ans, lorsque le quantique sera suffisamment démocratisé pour servir de serveur par défaut, si tous les génies de ces 30 dernières années vont livrer leur code source propriétaire Windows pour adapter leurs applications.

la technique n'y est pas pour toujours dans l'échec d'un projet....qu'on développe un projet sur PC vieux de 10ans avec 1 Mo de RAM ou un datacenter avec x serveurs en architecture distribuée ça ne change rien dans la réussite d'un projet et encore moins un ordinateur quantique

Je peux très bien acheter une scie circulaire dernier cri à 500 euros pour construire une table en contreplaqué et faire du travail médiocre...

Et puis comment on explique qu'un projet qui a coûté 200millions d'euros au contribuable donc n'a pas été mené à son terme ?
Le petit développeur qui fait son projet de jeu dans son coin il le publie sur un store ça fonctionne alors pourquoi un projet qui sollicite des grosses équipes ça ne fonctionne pas ?

[el_slapper]

Franchement, passé une certaine taille, il n'est pas raisonnable d'espérer réussir un projet en big bang. La seule faute d'IBM, c'est d'avoir accepté un projet impossible.

Typiquement, le genre de trucs quand je les ai vu marcher, ils étaient découpés en lots de 6 mois, voire moins. Au delà, on va dans le mur.

[shenron666]

1) Turnover veut dire que les gens du projet se sont barrés.
2) C'est une plaie de manager une grosse équipe.
3) Prend les deux points précédents et multiplies les entre eux.

1) Le turnover peut aussi venir de la hiérarchie qui préfère déplacer une ressource d'un projet vers un autre
2) Définis grosse équipe (10, 50, 100 personnes ?)
Ce n'est pas une plaie à manager, c'est une question de compétences, de répartition des rôles, de sérieux, d'implication...

[arond]

1) Le turnover peut aussi venir de la hiérarchie qui préfère déplacer une ressource d'un projet vers un autre
2) Définis grosse équipe (10, 50, 100 personnes ?)
Ce n'est pas une plaie à manager, c'est une question de compétences, de répartition des rôles, de sérieux, d'implication...

Pour la 1) Sa veut tout de même dire que des gens partent et viennent du projet ce qui nuira à l'organisation et surement au sérieux => l'implication des gens.
2) le projet avec une équipe de plus de 10 personnes je dirais.
Tout a fait d'accord c'est pour sa que j'ai pas dis que c'était impossible j'ai dis que c'était galère nuance.

[NSKis]

Si tous les projets informatiques qui foirent finissent au tribunal, il va falloir changer de métier et devenir... avocat!

[Grogro]

Tain c'est fou à quel point chaque ligne me fait sourire et m'évoque le projet mammouth sur lequel je galère depuis deux ans et pour lequel le client voulait initialement travailler en cycle en V pur et dur, sans pouvoir spécifier.

A part le couplet sur la malhonnêteté supposée des commerciaux d'IBM. Ca chez nous, j'en sais rien. Je pense quand même que les nôtres sont honnêtes.

[Ryu2000]

m'évoque le projet mammouth sur lequel je galère depuis deux ans et pour lequel le client voulait initialement travailler en cycle en V pur et dur.

Normalement les clients devraient être plus fan de méthode plus agile, des trucs itératifs, genre Scrum.
Comme ça le client il dit "je veux cette petite fonction en priorité", un sprint plus tard, le client vient voir la revue de sprint et il regarde la fonction réalisé.

Il vaut mieux faire fonction par fonction que tout d'un coup.
De toute façon le client va dire "je vous ai demandé cette fonction, mais en fait j'en ai pas besoin du tout. Par contre j'ai plein d'autres besoins que j'ai mal identifié".

[ddoumeche]

Franchement, passé une certaine taille, il n'est pas raisonnable d'espérer réussir un projet en big bang. La seule faute d'IBM, c'est d'avoir accepté un projet impossible.

Typiquement, le genre de trucs quand je les ai vu marcher, ils étaient découpés en lots de 6 mois, voire moins. Au delà, on va dans le mur.

Bizarre, car les constructeurs automobile y arrivent, et le MIT a bien réussit a sortir le programme de pilotage de la capsule Appolo dans les temps. Et il a marché du premier coup malgré un développement laborieux.
L'incompétence est sans doute aussi à rechercher du côté client, qui ne sait même pas ce qu'il veut et est incapable de dresser un inventaire de l'existant. Quand on voit le nombre de projet informatiques commandités par les administrations qui n'aboutissent pas ou sont sabotés suite à un changement de majorité.

Comme le disait un de mes architectes, au demeurant assez incompétent, le plus important dans un projet, ce sont les spécifications.

J'attendrais donc la décision du tribunal avant de me prononcer.

Tain c'est fou à quel point chaque ligne me fait sourire et m'évoque le projet mammouth sur lequel je galère depuis deux ans et pour lequel le client voulait initialement travailler en cycle en V pur et dur, sans pouvoir spécifier.
A part le couplet sur la malhonnêteté supposée des commerciaux d'IBM. Ca chez nous, j'en sais rien. Je pense quand même que les nôtres sont honnêtes.

C'est parce que tu passes trop de temps sur les forum à soutenir la cause du peuple que cela n'avance pas

[Grogro]

Bizarre, car les constructeurs automobile y arrivent, et le MIT a bien réussit a sortir le programme de pilotage de la capsule Appolo dans les temps. Et il a marché du premier coup malgré un développement laborieux.
L'incompétence est sans doute aussi à rechercher du côté client, qui ne sait même pas ce qu'il veut et est incapable de dresser un inventaire de l'existant. Quand on voit le nombre de projet informatiques commandités par les administrations qui n'aboutissent pas ou sont sabotés suite à un changement de majorité.

Peut-être que ce sont justement des projets gérés en interne, avec des ingénieurs expérimentés qui connaissent bien le métier, et pas par un presta cherchant le plus possible à tirer les coûts vers le bas, en promettant monts et merveilles, en vendant des débutants comme des experts, et ayant un turn-over très élevé.

[el_slapper]

Bizarre, car les constructeurs automobile y arrivent, et le MIT a bien réussit a sortir le programme de pilotage de la capsule Apollo dans les temps. Et il a marché du premier coup malgré un développement laborieux.

Ils étaient quelques poignées de développeurs. Ca reste une taille parfaitement gérable, pour un projet informatique. Tu regarde le programme logiciel du F35 à 16 millliards de dollars, et là, tu sais que ça ne peut pas marcher. Sans le savoir, les mecs qui ont pensé le Rafale l'ont dimensionné à la limite de ce qui était encore gérable. Du bon coté de la limite.

L'incompétence est sans doute aussi à rechercher du côté client, qui ne sait même pas ce qu'il veut et est incapable de dresser un inventaire de l'existant. Quand on voit le nombre de projet informatiques commandités par les administrations qui n'aboutissent pas ou sont sabotés suite à un changement de majorité.

En ce qui me concerne, sur ce point là, tu prêches un convaincu. Un projet sur mesure, ça se fait à deux. L'acheteur et le fournisseur. Et j'ai vu ce genre de clowneries à de nombreuses reprises dans le privé, pour exactement les mêmes raisons. Un connard qui veut se faire mousser, et qui refuse de corriger la moindre virgule sur les specs qu'il a signé de son sang(virgule qui a mis à la poubelle 360 années-homme de boulot, je le précise) parcequ'il a peur de passer pour un plouc. Je n'ai jamais bossé avec des administrations, mais si tu me dit que ça n'est pas mieux, je te crois sur parole. J4ai toutes les raisons pour.

Comme le disait un de mes architectes, au demeurant assez incompétent, le plus important dans un projet, ce sont les spécifications.

Oui et non. En fait, ça dépend ce qu'on appelle les spécifications. Si c'est le document sacré et inviolable fourni par le client, non, je ne suis pas d'accord, tous les projets non-triviaux vont bien au-delà de ça. Si c'est l'ensemble des demandes réalisées par le client, de manière formelle ou informelle, avant ou pendant la réalisation, alors je suis d'accord.

Peut-être que ce sont justement des projets gérés en interne, avec des ingénieurs expérimentés qui connaissent bien le métier, et pas par un presta cherchant le plus possible à tirer les coûts vers le bas, en promettant monts et merveilles, en vendant des débutants comme des experts, et ayant un turn-over très élevé.

En fait, c'étai un peu différent. A l'époque du projet Apollo, personne n'était expérimenté. C'était quelques douzaines de petits génies qui ont été balancés sans préparation, et qui ont fait ce qu'ils ont pu dans un contexte d'apprentissage dans tous les domaines. Une configuration qui n'existe plus, tu prends les mêmes petits génies aujourd'hui, ils ont une culture informatique forte. Et ne feront pas du tout les mêmes erreurs. Par contre, on leur demandera bien plus - au final, le pilotage d'Apollo, paradoxalement, c'est très simple.

Mais tu as raison sur le fond. Ajoute à l'incurie du client(justement soulignée par ddoumeche) l'incurie du fournisseur(qui n'est pas là pour faire le boulot mais encaisser les sous), et fatalement, tu arrives à des ignominies.

[ddoumeche]

Le software du F-35 peut marcher, et va marcher car les moyens sont sur la table et il n'y a pas moyen de faire autrement, mais même avec 15 000 développeurs, les gros projets sont lents et le produit sera mature opérationel dans 5 ans.
Avec donc 10 ans de retard sur le planning. Enfin, ils n'en sont pas à un éléphant blanc prêt.

Si même les spécifications des Airbus évoluent pour que les erreurs de conception et l’obsolescence soient traitées, je ne vois pas ce qui empêche des spécifications, software qui plus est, d'évoluer.
Il me semble aussi que Word a pu poursuivre son évolution et bénéficie de corrections et de service packs depuis le début de sa longue carrière.

A moins de se croire plus fort que tout le monde et d'imaginer pouvoir prévoir tout les cas possible d'usages et les évolutions, ce qui est un cas caractérisé de psychorigidité.

Il fut un temps où les projets aéronautiques de pointe étaient crées par des petites équipes d'ingénieurs très talentueux. C'est d'ailleurs une des méthodes préconisée dans The Mythical Man Month

[zecreator]

Puisque l'on parle d'IBM, Jérémie Caullet, ex Vice-Président de IBM Europe et ancien de chez Microsoft vient de prendre la Responsabilité du pôle Business Applications au sein de la Technology Consulting de PwC.