Il est de certains risques dont on sait qu'ils ont une très forte probabilité de se produire au cours du programme. Parmi ceux-ci, les risques inhérents à la conduite du changement dans l'organisation. L'introduction d'un catalogue de services dans une population d'utilisateurs habitués à appeler le service desk pour leurs demandes informatiques en est un. La mise en oeuvre d'une CMDB dans une organisation où chaque service conserve sa base de données d'éléments qu'elle gère, et joue sur la rétention d'information pour conserver certaines prérogatives, en est un autre. Le retard d'un programme lié au contexte politique est également un risque dont la probabilité d'occurrence est très forte. Sur la transformation d'une organisation informatique, les risques de cet acabit sont légion, et ils ont tous un point commun : la résistance naturelle au changement.
Alors comment éviter de foncer dans le mur, quand on est lancé à 100 km/h et qu'on SAIT qu'il y a un mur au bout ?
Trois possibilités : détruire le mur, faire un détour, ou enfin jouer au passe-muraille !
Détruire le mur : mitigation par la disparition du risque
Prenons l'exemple de la rétention d'information cité ci-dessus. Certaines personnes gardent leur base dans leur coin et sont les seuls à s'en servir et à connaitre les équipements dont ils sont en charge ?
Ce sont ces personnes qu'il convient d'identifier.
Vendre un projet de CMDB se fait par une approche "top-down" : le DSI, sponsor du projet, va aider à vendre le concept à ses lieutenants et au middle-management. Mais en parallèle, vous devez également adopter une stratégie "bottom-up". En allant voir ces personnes qui ont la connaissance de leur environnement, transformez-les en prescripteurs pour vous aider à faire passer le concept de CMDB dans leur équipe ! Ceux qui gèrent déjà les données de configuration seront les meilleurs CI owners.
Faire un détour : mitigation par l'évitement
Les risques liés au contexte politiques sont souvent résolus par une stratégie d'évitement. Pour éviter le mur, mieux vaut connaître sa longueur et tâcher de le rendre le plus petit possible. Vous avez connaissance des personnes dans l'organisation IT qui sont réticentes sur le programme ou qui interviennent négativement sur le programme. Ne vous confrontez pas directement à ces personnes, mais intervenez auprès de leurs pairs dans un premier temps, puis de leur management dans un deuxième temps. Si le programme est soutenu par ceux qui l'entourent, vous n'aurez peut-être pas besoin d'affronter votre détracteur frontalement.
Traverser le mur : stratégie de confrontation
"La meilleure défense c'est l'attaque".
Pourquoi ne pas appliquer cet adage à la maîtrise des risques ? A l'instar des pompiers qui allument des incendies maîtrisés pour en éviter de pires par la suite, l'une des façons de maîtriser un risque est de le provoquer, à un moment choisi et dans des conditions contrôlées. Comme un vaccin que l'on inocule pour forcer le corps à fabriquer ses défenses, vous pouvez forcer le risque à se produire.
Par exemple, dans le cadre d'un rejet à prévoir d'une solution par des utilisateurs que vous savez réticents, plutôt que d'attendre le déploiement et les réactions épidermiques de ces derniers, faites-en des parties prenantes de votre programme en leur proposant d'êtres pilotes sur votre nouveau processus ou outil. Ainsi non seulement ces utilisateurs vous rendront un fier service en détectant tous les problèmes dans le cadre des pilotes (et ils les accepteront car c'est bien à cela que sert un pilote), mais en plus ces utilisateurs qui auraient pu vous nuire par la suite se révéleront d'excellents prescripteurs et vous aideront lors du déploiement à grande échelle.
Connaissez vos risques, et affrontez les sans crainte ni sans attendre l'inéluctable. La détection des risques doit faire partie de l'ADN du directeur de programme, leur maîtrise s'acquiert par l'expérience et la le sang-froid.
