Projet planté : faut-il le sauver ou l’achever ?


Nous sommes souvent sollicités comme pompiers de grands projets informatiques en crise, dont l’informatique n’est souvent qu’une partie, mais sur laquelle se cristallisent les attentions. Nous avons réussi à sauver des projets notamment en appliquant des bonnes pratiques, mais sur certains, nous avons conclu avec nos clients que la meilleure chose était de prendre ses pertes, de pallier les dommages occasionnés par l’arrêt du projet, et de passer à autre chose.

Projet planté : faut-il le sauver ou l’achever ?

Tout était bien parti

De nombreux acteurs se sont réunis, se sont accordés pour lancer un projet « informatique » pour faire mieux, plus durablement, plus vite, moins cher, des activités existantes, ou faire du neuf, des choses que personne n’a jamais faites.

Liste des besoins priorisée, budget évalué par approches top-down et bottom-up convergentes, organisation en cycle en V ou en agile, porteurs métier, directeur de projet, architecte, techniciens, société de service, Direction des systèmes d’information, gouvernance de tout cela, choix de la priorité : délai-budget ou contenu… Vous avez tout bien organisé ou pas, le projet a commencé et quelques mois ou semaines avant l’ouverture aux utilisateurs, l’eau des pâtes commence à mousser et la casserole déborde. C’est la crise !

Pourtant, c’est la crise !

Les métiers hurlent : ils ne s’y retrouvent pas. Les utilisateurs se plaignent de l’ergonomie, de la couverture fonctionnelle, des performances.

Pourtant la DSI s’abrite derrière des arguments apparemment objectifs : le projet répond positivement point par point aux spécifications, et / ou les comités de pilotage, que personne n’a préparés correctement, et dont les compte-rendus ont été écrits par le Directeur de Projet, concluent que tout est sous contrôle.

Qui croire ?

La société de service commence à facturer des avenants, et à mettre dans ses compte-rendus à elle, qu’il va falloir choisir entre une rallonge substantielle de délais, donc de budget, ou renoncer à des fonctionnalités clés.

Apocalypse, now!

Pourquoi, comment en est-on arrivé là ?

Il existe maintes causes amenant un projet à la crise. Un projet est comme une chaine, il a la force de son maillon le plus faible. Notre pratique permet d’identifier les causes suivantes les plus courantes :

  • La liste au Père Noël, inadaptée aux moyens de l’entreprise, souvent due à l’absence ou la faiblesse du/des sponsors métier
  • L’incompétence du Directeur de Projet menant à une gouvernance inadaptée
  • Les choix de technologies exotiques, non éprouvées, non maitrisées
  • Le développement spécifique trop complexe
  • La société de services défaillante
  • Une communication inexistante, des utilisateurs non formés

D’autres conditions de réussites existent en fonction du contexte.

Bien sûr, et malheureusement, le panachage de causes est possible et fréquent.

Que faire quand c’est la crise ?

Faire appel à nous, bien sûr ! 🙂

Blague à part, dans le tourbillon d’émotions, de jeux politiques, financiers, et les disputes, la première chose à faire et d’objectiver et de structurer les problèmes. Et la meilleure manière de le faire est de faire intervenir un tiers externe. Pourquoi ? Parce que :

  • il n’a pas de responsabilité dans les choix faits qui ont amené à la situation présente
  • il est neutre : il n’a pas d’intérêts dans la suite, l’arrêt définitif ou la reprise à zéro du projet
  • il ne risque pas sa carrière s’il déplait à untel ou une telle par ses constats et recommandations. Il va donc les formuler librement, sans filtre, sans autocensure,
  • c’est un expert : s’il est bien choisi, il a déjà vécu des dizaines de cas comparables, il connait bien la culture, les « usual suspects » et sait donc vite et justement, identifier les causes et les remèdes

Cet expert va donc s’atteler, au travers d’analyses et de rencontres, à comprendre d’où on est parti, pour quoi faire, avec quels moyens, en temps et en argent, comment, avec qui, dresser une liste de constats, les structurer par thèmes, et livrer des recommandations.

Exemple de structuration d’audit de projet, suivant le business model canvas

Plusieurs issues à la crise

A la fin de l’audit, il y a trois issues possibles :

  • La poursuite avec des ajustements : moyennant quelques recommandations, parfois coûteuses ou douloureuses, le projet peut être sauvé
  • L’arrêt définitif : on s’est attaqué à l’Everest en tongs, le projet n’était pas réaliste dans le contexte. Il faut arrêter et passer à autre chose
  • La reprise à zéro : tel qu’engagé, le projet n’a pas d’issue. Mais la couverture du besoin reste vitale. Il faut prendre ses pertes et repartit à zéro.

Évidemment, les deuxième et troisième choix sont cornéliens. Même en étant le dirigeant de la société, accepter d’arrêter un projet est difficile, d’autant plus qu’on a expliqué que c’était important, qu’on a mis son crédit dans la balance, et que l’entreprise vous regarde et que certains seront trop heureux d’utiliser la situation pour vous nuire. C’est bien pire si on est un des membres du CODIR de la société, et que vous pensez que vos collègues Directeurs ou le DG ou le Président vont vous envoyer au purgatoire, au placard, à Pôle emploi.

Au-delà de ces enjeux politiques, opérationnellement il faut prévoir un « plan B » : maintenant qu’on sait qu’on n’aura pas l’actif informatique attendu, ou alors dans très longtemps, comment pallier son absence ?

En tout état de cause, ce qu’il faut bien avoir à l’esprit, c’est d’éviter l’escalade de l’engagement. Ce n’est pas parce qu’on a déjà dépensé 10 M€ dans le projet qu’il faut en remettre encore, si on n’a aucune garantie de bonne fin. Les 10 M€ ont été dépensés, ils sont IRRÉCUPÉRABLES. Inutile d’en rajouter. Je vous invite à consulter cette video pour déjouer ces mécanismes mentaux délétères.

Réussir à prendre toutes ces décisions difficiles et d’assumer la situation est le signe d’une organisation mature, saine et résiliente, qui sera capable dans l’avenir de réussir d’autres projets car elle aura appris de ses erreurs.

Philippe Kalousdian

Philippe Kalousdian a fondé ISlean consulting avec Eric Villesalmon en 2008. Son métier consiste à apporter le progrès technologique aux décideurs. Il a débuté comme ingénieur du cycle nucléaire à SGN/Areva. Il rejoint Bossard-Gemini consulting en 2000. Philippe est diplômé de MINES ParisTech, membre CA MINES ParisTech Alumni de 2010 à 2018, est membre fondateur de X-Mines Auteurs et du MOM 21. Il aime le ski et la moto. Il connecte des univers lointains, ce qui crée de la valeur par sérendipité. Depuis 2014, il accompagne des start-up, dont Color Grail et AYO Lab.

About the Author:

Philippe Kalousdian
Philippe Kalousdian a fondé ISlean consulting avec Eric Villesalmon en 2008. Son métier consiste à apporter le progrès technologique aux décideurs. Il a débuté comme ingénieur du cycle nucléaire à SGN/Areva. Il rejoint Bossard-Gemini consulting en 2000. Philippe est diplômé de MINES ParisTech, membre CA MINES ParisTech Alumni de 2010 à 2018, est membre fondateur de X-Mines Auteurs et du MOM 21. Il aime le ski et la moto. Il connecte des univers lointains, ce qui crée de la valeur par sérendipité. Depuis 2014, il accompagne des start-up, dont Color Grail et AYO Lab.

Leave A Comment