Sélectionner une page

La compréhension des raisons pour lesquelles un projet informatique dérive peut être rapide. Ce qui demande plus d’expérience, c’est de comprendre l’articulation des différentes causes de dérive, de savoir les prioriser et de mettre en face les bonnes mesures correctives.

Tandis que je réfléchissais à concevoir une offre de conseil dédiée au redressement des projets en difficulté, quels qu’ils soient (intégration, infogérance, tierce maintenance, développement, etc.), j’ai cherché une sorte de « tronc commun » des causes de leur dérive. Après avoir analysé plusieurs dizaines de cas de projets ayant échoué, j’ai pu en modéliser les causes. Cela m’a permis de disposer d’une matrice de base très intéressante pour procéder à une analyse rapide de la situation.

Il est en effet primordial de passer le moins de temps possible sur l’état des lieux d’un projet en échec et d’engager rapidement des actions correctives. Cela est nécessaire pour les protagonistes qui ont besoin de croire à nouveau à la bonne fin du projet et de retrouver une ambiance de travail constructive.

Les causes de l’échec peuvent être identifiées de la manière suivante :

  • La perte de la maîtrise du périmètre fonctionnel en raison d’oublis lors de l’expression initiale des besoins ou de l’expression de nouveaux besoins lors de la phase d’analyse fonctionnelle (post contractuelle) ;
  • Le facteur humain : il s’agit tant des égos surdimensionnés que des « moins utiles » qui se cachent derrière la conscience professionnelle des « plus utiles », ces derniers passant leur temps à compenser l’inefficacité des premiers.
    La dérive provient souvent d’un chef de projet qui, bien que le projet nécessite sa présence à temps complet, est en réalité accaparé par de multiples autres responsabilités. Ainsi le premier concerné par la mise en place d’un « capacity planning » manque lui-même de temps…
    Elle peut également provenir d’un manque de formation aux basiques de la gestion de projet, qui engage le projet sur de mauvaises bases.
  • Le facteur contractuel : c’est une cause régulière de dérive des projets informatiques. Voir le précédent article sur le piège du contrat au forfait.
    On trouve dans certains contrats un Plan d’Assurance Qualité ou un Plan Qualité Services. Ces documents sont souvent disproportionnés et manquent cruellement de pragmatisme. Ils sont de fait abandonnés par les opérationnels et ne jouent absolument pas leur rôle de référentiel contractuel.
  • Le facteur assurance qualité / la gouvernance : la difficulté réside dans le délitement de leur application au fur et à mesure du projet, au profit de la gestion de l’opérationnel. Or, lorsqu’un projet est en situation de dérive, l’assurance qualité et la gouvernance sont précisément des sujets qu’il importe de traiter en priorité afin de restructurer l’organisation du projet, les flux d’informations et les canaux de communication.
  • Le facteur technique/technologique : il peut toujours y avoir des difficultés techniques ou technologiques. Lorsqu’elles sont importantes, le projet doit parfois s’arrêter car ce qui est impacté est la raison d’être du projet.

A titre d’exemple, nous citerons ce projet d’intégration d’un ERP majeur du marché qui n’aboutissait pas, car l’un des modules n’était pas livré par l’éditeur. Après plusieurs mois de tergiversation, il s’est avéré que le module n’était pas finalisé techniquement, et était en quelque sorte en « laboratoire »… C’est l’une des rares fois où nous avons préconisé d’arrêter le projet car le module était stratégique pour notre client.

Nous avons présenté les causes de dérive des projets informatiques de manière globale.

En tout état de cause, le débat est ouvert et j’espère que vous, lecteurs n’hésiterez pas à faire part de vos propres expériences et de vos avis.