Échecs de projets

Encore une fois les choses ne se présentent généralement pas aussi simplement que vous pouvez le penser. Pour vous, un projet est une réussite ou un échec, cela semble indiscutable. Et poutant...

Pour illustrer voici un exemple assez ancien :
Dans les années 1998-1999, une banque (appelons la BBE) a confié à un cabinet de conseil de renomée mondiale la réalisation d'un outil pour les conseillers en agence "Outils Commerciaux Agence" (OCA) cela a été fait par le prestataire mais avait la particularité de ne pas passer l'an 2000 pour des problèmes de gestion de date (cf toute la problématique an 2000 dont vous avez peut-être entendu parler).
C'est apparement un échec, le cabinet a manqué à son devoir de conseil, il y a faute.
Ce qu'a fait la BBE : ils ont refait dans l'urgence avec des équipes internes une application OCA et ont "jeté" ce qui avait été fait par le cabinet. Au niveau financier je ne sais pas ce qui c'est passé mais je suppose que la BBE a payé au moins une grande partie de la facture.
C'est manifestement un échec. Pour qui ? Pour la BBE surement : perte de temps, perte d'argent. Pour le cabinet, pas si sûr, certes le client est mécontent et il sera peut-être difficile de refaire des affaires avec lui (quoique avec le nom mondialement renommé du cabinet on trouve des clients facilement), mais le projet a été réalisé, je suis quasiment persuadé que la compatibilité an 2000 ne devait pas être indiquée dans le contrat initial et que la BBE aurait du payer en plus pour cette "fonctionnalité" supplémentaire, les factures du projet ont donc probablement été réglées, alors, de quoi se plaindre ?

Autre exemple :
Une application de gestion des débiteurs pour le Crédit Agricole. Application souhaitée par la CNCA pour les caisses régionales. Les caisses régionales trainent un peu les pieds, on arrive quand même à avoir deux caisses pilotes (sur 3 souhaitées). Le projet se déroule, il est mis en production, les caisses pilotes sont satisfaites. Mais il n'y aura pas de déploiement. Les choix techniques ne sont pas entièrement conformes à la politique des caisses régionales, le sponsor (à la caisse nationale) est parti à la retraite entre temps... Mais les 2 caisses pilotes sont très satisfaites de leur application...
Alors échec ?
Du point de vue du prestataire, le projet a été réussi dans les délais avec respect des coûts et des charges.
Du point de vue de l'équipe projet CNCA aussi, le projet pilote est arrivé au bout...
Mais il n'y a pas eu de généralisation et il est fort probable que cette application disparaisse à terme suite aux différentes réfontes de systèmes d'information.

La notion d'échec n'est donc pas aussi simple que cela... C'est souvent une question de point de vue.
La problématique des projets informatiques n'est pas très différente des autres projets (regardez le tunnel sous la Manche, comme projet qui pourrait être considéré comme un échec, ou l'implantation de DisneyLand Paris).
La principale difficulté, réside peut-être dans le caractère "immatériel" de la livraison qui peut laisser penser à certain qu'on peut modifier les spécifications à tout moment...
La dérive des projets n'est pas un problème "informatique" (cf tunnel sous la Manche) il est à mon avis lié à la nature humaine et à deux choses :

• la tendance "optimiste" des estimations initiales (quand elle n'est pas délibérée pour "avoir l'affaire/le budget/le contrat")
  

• la difficulté à renoncer quand le processus est engagé (cf les travaux de Joule sur l'engagement dans un domaine légérement différent)
  

à partir de là il est assez facile de faire exploser les budgets...

Un autre point, il y a rarement échec suite à une impossibilité technique incontournable (on ne sait pas faire), ces difficultés sont vues en amont. L'échec est toujours du type "on ne sait pas faire avec le budget et/ou le délai prévu", donc en remettant la main au portefeuille on peut essayer d'y arriver, mais quelle est la taille du portefeuille et combien est-on prêt à y mettre ?

Je vous donne une petite biblio sur la gestion de projet (plutôt informatique) et les sujets évoqué dans ce billet :

• Le mythe du mois-homme de Frederick P Brooks Jr assez ancien mais tjs d'actualité
  

• The Deadline de Tom DeMarco une nouvelle en anglais sur le sujet
  

• Petit traité de manipulation à l'usage des honnêtes gens par Robert-Vincent Joule et Jean-Léon Beauvois
  

• Peopleware de Tom DeMarco & Timothy Lister plus sur la gestion des ressources humaines
  

• dans un domaine différent, Les décisions absurdes de Christian Morel (il décortique notamment le cas DineyLand Paris, existe en folio)

Internet et e-commerce

Ce sujet peut paraître un peu réchauffé, cependant, on peut aujourd'hui examiner les choses avec un peu de recul. Retournons donc quelques années en arrière...

À la base deux composants :

• un moyen de diffusion dont le coût n'est pas (ou peu) proportionnel à la diffusion pour diffuser le catalogue
  
• des techniques qui permettent de faire faire la saisie de la commande au client
  

Les techniciens auront reconnu le réseau de communication Internet et le cadre de protocoles et d'outils applicatifs associé (HTTP,HTML, J2EE, etc.).

Ce sont les deux ingrédients qui ont permis au commerce par correspondance de devenir le e-commerce.
Les opérateurs de vente à distance en on profité, mais aussi d'autres acteurs qui voyaient là l'opportunité de démarrer un commerce avec comme audience le "village mondial". Les premiers avaient déjà l'infrastructure pour traiter du courrier, des appels téléphoniques, du Minitel... Ils ont ajouté une interface avec le Web. Les nouveaux entrants ont tout traité en même temps en créant leur système d'information à partir de rien.

Et le multi-canal dans tout cela ?
À cette époque de nombreux cabinets de conseil en faisaient grand cas, le client devait être traité de la même manière quelque soit le canal de contact. C'est une intention louable. Elle est un peu utopique : si j'ai l'habitude d'un canal je vais en principe m'y tenir, a fortiori, si j'ai un "dossier" en cours, je vais essayer de conserver le même interlocuteur. Dans un monde idéal, tous mes interlocuteurs potentiels ont le même niveau de connaissance... Ce n'est donc pas une histoire de canal mais bien une affaire de partage d'information entre tous les employés.

...C'est une tarte à la crème inventée par les cabinets de consulting.
Avec ce terme à la mode, de nombreux cabinets ont convaincu leurs clients de brancher ensemble des applications de gestions anciennes et de nouvelles dédiées aux nouveaux canaux. Évidemment cela rend le tout un peu compliqué, c'est une bonne opportunité...

D'autres ont réfléchi à l'architecture avec bon sens :
Regardez les boutiques dans lesquelles les vendeurs sont remplacés par des terminaux permettant de commander comme sur Internet, elles n'ont pas eu besoin de consultants pour comprendre que leur nouvel outil informatique de prise de commande / gestion de stock conçu pour Internet (et qui est bien plus convivial que le précédent) pouvait aussi être utilisé en magasin.
Dans le groupe Mulliez (reputé pour son pragmatisme), c'est le site Internet qui est utilisé en magasin pour consulter le catalogue.

Donc, de multi canal point, juste une réflexion sur l'architecture des systèmes d'information, comme quoi, un ajustement des points de vue est parfois bien utile.