« Ils ne savaient pas que c’était impossible, alors ils l’on fait » (Mark Twain)
Un projet informatique réuni plusieurs intervenants dont les intérêts peuvent diverger au cours de la réalisation de celui-ci. Le contrat au forfait notamment, porte en son sein dès sa signature les raisons de cette discorde.
Recadrer un projet a toujours plus d’intérêt que l’échec qui conduit à la destruction pure et simple de l’investissement et dont les coûts directs et indirects sont d’au minimum 3 fois supérieurs au coût d’un recadrage.
Il y a cependant deux prérequis à la réussite d’un recadrage : la communication doit subsister entre les différents protagonistes et une évolution à la hausse du coût du projet devra être acceptée par le client.
La modélisation des causes de dérive permet d’accélérer la phase d’audit des difficultés.
Tant qu’il y a de la communication il y a de l’espoir !
Comment détecter qu’un projet ne se porte pas bien ? Au nombre d’emails échangés ! En grossissant à peine le trait, on peut dire que le nombre d’emails est proportionnel à la difficulté que rencontrent les protagonistes à se parler directement et surtout, à se comprendre (cf. notre précédent article sur le rôle du médiateur dans l’entreprise[1]). Ainsi, lorsque le volume quotidien d’emails devient impossible à gérer et que l’ambiance est tendue… il importe de se pencher sur la santé du patient.
Un autre signe qui ne trompe pas : les échanges sont principalement orientés autour de la responsabilité des uns et des autres afin de pouvoir se dédouaner d’un éventuel échec du projet. La nature humaine est telle, que le premier réflexe devant une difficulté consiste à chercher des poux dans la tête de l’autre.
Qui plus est, la décision de faire intervenir une tierce partie pour recadrer le projet est parfois tardive et les équipes d’une part sont usées et d’autre part ont accumulé des sentiments négatifs.
Lorsque nous intervenons, la première réunion est toujours consacrée à ce que les psychologues appellent « la purge émotionnelle ». L’image n’est pas des plus agréable, mais c’est efficace !
Il importe absolument de dépasser ce stade des reproches, au risque de tourner en rond et de continuer à cristalliser le débat. Ce que j’aime à dire lors de ces premières rencontres et qu’il y a des salles de réunion pour échanger sur les responsabilités qui s’appellent des tribunaux. Or s’il nous est demandé d’intervenir, c’est que nous ne sommes pas au tribunal, il faut donc que les parties dépassent leurs griefs et leurs frustrations et changent leur état d’esprit pour se remettre dans une dynamique constructive (« One team »).
Il est essentiel que la communication subsiste entre les différents protagonistes, d’où l’importance d’être réactif afin de ne pas atteindre le point de non retour, souvent synonyme d’un contentieux inéluctable. Par ailleurs, plus tôt la décision sera prise moins longue sera la période de recadrage.
Revoir le coût du projet à la hausse : le cas du contrat au forfait.
Prenons l’analogie du concessionnaire de voiture pour comprendre à quoi peu conduire un contrat forfaitaire dans le cadre d’un projet informatique.
Pour la société utilisatrice de la future solution informatique, cela revient à choisir un modèle de voiture et à le configurer avec de multiples options. Un contrat et alors signé, détaillant précisément ce que contient le modèle de série complété de toutes les options demandées et le prix qui en résulte.
Dans une concession automobile, l’histoire s’arrêterait là et vous attendriez patiemment la livraison de votre belle berline.
En informatique ce n’est pas toujours le cas ! Le « concessionnaire » peut certes vous faire signer un contrat (à un prix permettant de s’assurer le gain du marché…), mais indiquer dans le même temps qu’il faudra rediscuter de certaines options afin de préciser vos besoins, c’est la phase d’analyse fonctionnelle.
Naturellement le client, qui est amené a posteriori à réfléchir à nouveau avec plus de précision à ses besoins, va se rappeler qu’il a oublié le radar de recul, le limiteur de vitesse et va tenter d’obtenir ce qui n’a pas été accepté pendant la négociation contractuelle. Autant d’options hors forfait !
Cette situation conduit nécessairement l’intégrateur à réévaluer à la hausse son budget pourtant initialement forfaitaire ce qui place les parties dans une situation délicate. On appelle cela « faire fonctionner la machine à avenant ».
Les modalités des projets qui s’appuient sur un contrat au forfait conduisent nécessairement, à un moment ou à un autre et notamment lorsqu’il s’agit de les recadrer, à (ré)évaluer le coût réel du projet. Ainsi, si le client a la volonté de le faire aboutir, il se doit très souvent (pour ne pas dire toujours) de compléter l’enveloppe budgétaire initialement prévue.
Certes, le coût d’un échec est toujours supérieur au coût d’un recadrage d’un projet, mais la pilule peut être difficile à faire avaler à une Direction Générale.
Faire un état des lieux « flash » : la modélisation des causes de dérive.
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.
Après plus de dix années passées à accompagner les cabinets d’avocats dans leurs dossiers de contentieux en informatique, alors que j’étais consultant dans un cabinet d’expertise en informatique, j’ai appris de tous ces projets qui ont échoué les causes de leur échec.
Alors que je réfléchissais à concevoir une offre de conseil dédiée au redressement des projets en difficulté, j’ai souhaité comprendre s’il y avait une sorte de « tronc commun » des causes de dérive et d’échec quels que soient les projets informatiques (intégration, infogérance, tierce maintenance, développement, etc.).
Après l’analyse de plusieurs dizaines de cas de projets ayant échoué, j’ai pu modéliser les causes de dérive et d’échec des projets informatiques, ce qui représente une matrice de base très intéressante pour procéder à une analyse rapide d’une situation.
Il est en effet primordial, de passer le moins de temps possible sur l’état des lieux d’un projet en situation de dérive et d’engager rapidement des actions correctives. Cela est nécessaire pour l’entreprise qui souhaite que le projet aboutisse dès que possible ainsi que pour les protagonistes qui ont besoin de croire à nouveau à la bonne fin du projet et de retrouver une ambiance de travail constructive.
Par conséquent, nous ne recommandons pas d’initier une phase d’audit longue suivi d’une restitution et d’engager par la suite les mesures de redressement. Cela peut conduire à perdre au minimum un mois avant d’engager des mesures pourtant évidentes.
Cette évidence résulte de la modélisation des causes de dérive qui dans les grandes lignes, est la suivante (on notera que l’ordre d’importance dépend du contexte) :
La perte de la maîtrise du périmètre fonctionnel en raison d’oublis lors de l’expression initial 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 egos 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 (principe de compensation qui à termes peut conduire à l’épuisement des « plus utiles »).
De plus en plus, « le facteur humain » concerne également la capacité à produire. En effet, a force de réduire les effectifs les entreprises se trouvent à devoir accumuler les responsabilités sur des équipes de moins en moins fournies. 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…
Enfin, il reste bien entendu la formation. Très souvent, le rôle de directeur ou de chef de projet est assigné à des collaborateurs qui font preuve de beaucoup de bonne volonté, mais qui n’ont pas été formés ne serait-ce aux basiques de la gestion de projet. C’est un risque réel, car le projet risque d’être engagé sur de mauvaises bases ce qui rend le recadrage plus complexe.
Le facteur contractuel : nous ne reviendrons pas en détail sur le cas des contrats au forfait exposé précédemment, mais force est de constater que c’est une cause régulière de dérive des projets informatiques.
Plus généralement, le contenu des différents contrats informatiques est arrivé à « maturité ». En effet, il est rare de trouver des contrats incomplets dans lesquels il manquerait des clauses essentielles et/ou des annexes.
Il y a quelques années cela pouvait être le cas, mais la tendance s’est inversée. En effet par exemple, on trouve désormais dans les contrats qui le nécessite un Plan d’Assurance Qualité ou un Plan Qualité Services, mais c’est 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 : s’agissant des principes d’assurance qualité et des règles de 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 (c’est-à-dire du quotidien). 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, les canaux de communication, etc.
Force est de constater que ces sujets sont parfois négligés dès le début du projet puisque par souci d’économie, on s’abstient d’adjoindre au chef du projet un « PMO » qui peut efficacement organiser et animer la gouvernance du projet et les actions qui relèvent de l’assurance qualité.
Le facteur technique/technologique : contrairement à ce que l’on pourrait croire, ce facteur est loin d’être le plus concerné par les causes de dérive d’un projet informatique. Bien entendu, il peut toujours y avoir des difficultés techniques/technologiques, mais lorsqu’elles sont importantes, le projet doit parfois tout simplement s’arrêter car ce qui est impacté est la raison d’être du projet.
A titre d’exemple, je citerai ce projet d’intégration d’un ERP majeur du marché qui n’aboutissait pas, car 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, il é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érives des projets informatiques de manière globale. Chaque cause peut être détaillée en sous-causes qui appellent des mesures correctives spécifiques.
En tout état de cause, le débat est ouvert et j’espère que les lecteurs n’hésiteront pas à faire part de leurs propres expériences et de leurs avis.
Dans une prochaine seconde partie de cet article, nous présenterons les mesures correctives qui font partie des incontournables du recadrage de projets informatiques en difficulté.
[1] http://www.lesechos.fr/idees-debats/cercle/cercle-154913-instaurer-un-mediateur-dans-lentreprise-pour-recreer-du-lien-et-developper-la-comprehension-entre-vos-collaborateurs-1205170.php
