C’est un des effets pervers de la diffusion des bonnes pratiques : associer à chaque projet des KPI (Key Performance Indicators), ou indicateurs clés de performance. Plus rien ne peut plus se faire sans que l’on nous demande, voire exige, l’élaboration de ces fameux indicateurs.
Cela part d’une bonne intention et correspond à la question légitime que se posent les métiers et les équipes de la DSI : « Quels sont les éléments les plus pertinents qui garantissent la réussite d’un projet ? » Et à la question sous-jacente : « Comment être sûr de ne pas me faire arnaquer par la DSI ? »
Au début, je trouvais que c’était une excellente idée, mais, avec le temps, cela devient de plus en plus une corvée. D’abord, parce que l’on passe de nombreuses heures en réunion à élaborer lesdits indicateurs, surtout quand personne ne s’accorde sur leur contenu, de bonne ou de mauvaise foi ! Ensuite, parce que l’on passe autant de temps à identifier la manière de calculer les indicateurs, l’objectivité n’est pas toujours de mise… Evidemment, personne n’est d’accord et chacun veut mettre en avant l’indicateur le plus facile à calculer. Surtout celui qui sera toujours au vert, histoire de ne fâcher personne et de dégager sa responsabilité en cas de problèmes (qui surviennent dans quasiment 100 % des projets). Enfin, parce qu’une fois que l’on a défini des indicateurs, plus personne ne les regarde ! Tout ça pour ça…
J’ai donc pris une décision radicale, applicable immédiatement : remplacer les KPI par les KFI, les Key Failure Indicators. A la différence des KPI, qui se calculent le plus souvent a posteriori, les KFI se calculent avant le lancement des projets. Cela permet de voir si on va dans le mur « à coup sûr », « peut-être bien », « sûrement » ou « ça va, mais faites gaffe quand même ». Je n’ai pas retenu la catégorie « tu peux y aller, tout est au vert », qui relève de la science-fiction. Evidemment, pour ne pas froisser nos amis et néanmoins collègues des métiers, je garde mes KFI pour moi. Officiellement, nous conservons des KPI pour nos projets mais ce sont, comme on l’indique dans des vitrines de magasin, « des produits factices ». D’ailleurs, le célèbre philosophe K.Sla n’Tien disait : « L’essentiel est d’atteindre son BUT (Balader les Utilisateurs Tranquillement). »
Je vous livre quelques-uns de mes principaux indicateurs que vous puissiez les appliquer si vous voulez vraiment connaître la probabilité de plantage d’un projet.
- La proportion d’interlocuteurs, côté métier, qui ont la réputation d’être compétents, sérieux et motivés. C’est souvent facile à calculer, un rapide sondage parmi vos équipes et vous saurez si on vous a envoyé les seconds couteaux, voire des interlocuteurs qui ont la réputation de défaire tout ce qui a été fait. Et plus ils sont nombreux, plus c’est problématique, selon le « principe d’Archi-emmerdes » : « Tout DSI plongé dans un projet subit une pression désagréable qui s’exerce du haut de la hiérarchie vers le bas, et qui est proportionnelle au poids des volumes de processus déplacés et des parties prenantes. »
- La part des consultants juniors dans l’équipe d’intégrateurs ou de consulting. Comme pour l’obtention des prêts immobiliers, il ne faut pas dépasser un tiers des ressources disponibles. Certes, il faut bien que les juniors se fassent la main, mais c’est mieux s’ils opèrent chez vos concurrents. Le nombre de versions du cahier des charges : c’est le signe que le métier ne sait pas ce qu’il veut. Inutile donc de leur proposer quoi que ce soit, cela changera la semaine suivante (périmètre, fonctionnalités, priorités…). Et laissez-les se débrouiller directement avec les fournisseurs, ça leur apprendra à avoir développé le shadow IT en vous ignorant pendant des années.
- Le nombre de retours d’expérience clients que les éditeurs de logiciels ou les cabinets de conseil vous proposent. Si c’est zéro, c’est peut-être le fait que la solution logicielle vient se sortir (mais êtes-vous sûr d’être volontaire pour passer en premier ?) ou que les clients ont un peu honte de s’être fait balader et préfèrent qu’on les oublie.
- La durée envisagée du projet. C’est le domaine où la prévision a été, est et sera fausse dans tous les cas ! Et on ne peut même pas appliquer une règle de type « durée réelle = 2x durée prévue », les projets étant par définition spécifiques, même avec des technologies similaires. Plus les prestataires s’engagent fermement sur un délai, plus il faut se méfier…
- Le nombre de réunions de pilotage prévues pour mener le projet. Vous avez le choix entre zéro (là, c’est clair que tout le monde s’en fout…) et plusieurs centaines (là c’est clair aussi que tout le monde s’en fout aussi, mais les réunions sont pratiques pour trier les e-mails en retard ou parce que le café y est meilleur qu’à la machine du deuxième étage…).
- Le nombre de tâches pour lesquelles on peut identifier au moins un responsable. Si le ratio est inférieur à 90 % et, pire, que les 10 % restant concernent des missions critiques (au hasard, les tests…) le projet est mal parti.
Imaginez un projet majeur de transformation, qui doit être menée en moins d’un mois, avec des key users qui n’en ont rien à faire, géré en toute autonomie par une majorité de consultants juniors, après vingt-cinq versions du cahier des charges, sans aucune réunion de pilotage et pour lequel on se sait pas qui est responsable de quoi. Ne rigolez pas : ça n’arrive pas qu’aux autres !