Les projets : la gloire du CIO ou son cimetière.

Ou comment la réussite des projets sous la responsabilité du CIO peut consacrer son succès.

Nous avons encore tous en mémoire les déboires, ces dernières années, de certaines organisations en matière de sécurité informatique (données, accès, etc.) et l’impact que cela a eu sur leurs clients et sur l’image de ces entreprises. On a vu aussi que cela a couté leur place à certains CIOs. On a juste à penser à Desjardins. Mais savez vous quelle est la deuxième raison en importance pour laquelle les CIOs sont congédiés, ou perdent grandement leur pouvoir à l’intérieur des organisations, après les brèches de sécurité ? C’est l’échec des projets.

Les projets pour concrétiser la vision du CIO et asseoir son rôle

Les projets sont une opportunité d’être ailleurs, meilleur, plus adapté à son environnement

Parmi les missions importantes d’un CIO, il y a celle de développer et livrer une vision pour son département. Vision qui devra jouer un rôle dans le support de la réalisation de la stratégie globale de l’entreprise. La réalisation de cette mission passera nécessairement par la définition et la mise en œuvre de plusieurs projets qui deviendront le moyen de concrétiser cette vision. Les projets sont des outils puissants de changement, d’évolution et d’adaptation des entreprises en général et des départements TI en particulier. Ils ne sont pas une fin en soi, bien sûr. Ils sont une opportunité d’être ailleurs, meilleur, plus adapté à son environnement et à ses besoins.

Aujourd’hui, en parlant de mission, les CIOs sont des leaders d’innovation dans l’entreprise et leurs services sont autant d’être la colonne vertébrale dans la réalisation de la stratégie d’entreprise y compris sa stratégie numérique, que d’être la pierre angulaire de l’optimisation des coûts TI et affaires, ou d’identifier les opportunités de différentiation pour la business.

Ils sont partout et dans tous les domaines de l’entreprise depuis la création d’un nouveau produit, à la décision de mieux se positionner sur le marché ou de répondre à la stratégie d’un concurrent, au changement dans les façons de faire pour combler une faiblesse ou accroitre l’impact d’une force et jusque dans la mise en œuvre d’un changement dans la culture quand elle n’est plus adaptée. Implanter ou changer une technologie ou une solution, intégrer, optimiser les coûts du département des technologies de l’information (TI), opérer un virage technologique ne sont là que pour mieux positionner les TI pour la réalisation de la stratégie d’affaires de l’entreprise. Les enjeux sont donc tous affaires et d’une grande importance.

Réussir les projets ou mourir

Les projets initiés ont un impact majeur, autant sur l’entreprise que sur les CIOs, leur réputation, leur carrière

Plus que jamais, les projets initiés ont un impact majeur. Et ils en ont autant sur l’entreprise que sur les CIOs eux-mêmes, leur réputation et leur carrière. Réussir ou échouer ces projets représente donc la gloire pour ces CIOs, si l’impact est positif, ou leur cimetière, sinon. On a vu des projets qui semblaient parfaitement innocents coûter des carrières très prometteuses de CIOs. En effet, que vaut une vision lumineuse si sa mise en œuvre ne se réalise pas ou rate son timing et son rendez-vous.

Les projets sont l’action. Ils permettent de mettre en mouvement la vision que les CIOs se sont donnée. Les réussir c’est diriger l’entreprise dans la direction qu’elle s’est donnée, vers les objectifs et les rêves dont elle s’est dotée. Ne pas les entreprendre ou les échouer c’est amener l’entreprise dans une autre direction. Une direction que l’on n’a pas choisie et qui est donc des plus hasardeuses. Et nous ne parlons pas d’argent, ce qui pourrait s’avérer, en effet, être un souci mais de moindre importance. En effet, se laisser dépasser par la concurrence, ne pas être capable répondre aux besoins des clients de l’entreprise ou rater l’exécution de la

Les projets sont l’action. Ils permettent de mettre en mouvement la vision que les CIOs se sont donnée

stratégie de l’entreprise pourrait avoir un impact bien plus grand. Voire menacer sa survie. Rappelez-vous quand Hershey’s avait réussi à produire finalement ses friandises mais quelques semaines après la période où la demande était au rendez-vous. La catastrophe ne tient pas à grand-chose. Ou la disparition de la pharmaceutique FoxMeyer à cause de la mise en œuvre de l’ERP SAP et d’une solution de gestion d’entrepôt et leur intégration, non réussies.

Les dangers pour un projet sont tout au long du processus

Mais que faire alors ? La santé et la prédisposition à bien aller ou mal aller d’un projet commence bien en amont du début de son exécution, se continue tout au long du processus d’exécution et va au-delà de la fin de ce dernier.

Ces projets mort-nés

Bien aller ou mal aller pour un projet commence bien en amont du début de son exécution, se continue tout au long du processus d’exécution et va au-delà de la fin de ce dernier.

L’échec peut donc prendre ses racines très tôt dans le processus. Avant même de parler de réalisation. Les occasions pour préparer l’échec sont nombreuses. On peut, par exemple, faire l’impasse sur une quantification des bénéfices, comme je le vois souvent dans les entreprises. Pourtant, à bien y penser, ce ne sont pas les coûts qui sont le garde-fou des projets mais bien les bénéfices. On arrête ou on annule un projet seulement quand la réalisation de ses bénéfices n’est plus possible, ou alors quand la fenêtre d’opportunité est passée. Pas seulement en regardant ses coûts ou en prononçant la phrase magique « c’est trop cher ». Trop cher par rapport à quoi? On ne possède aucun étalon de comparaison si on n’a pas de bénéfices chiffrés. Un autre problème qui nait lors de la phase de préparation du projet, c’est celui où, par manque de rigueur, on coupe court aux options de solutions et on prend la première qui se présente ou celle que le « voisin » a choisi. On se retrouve alors en train de réaliser le mauvais projet. Une autre erreur courante est celle où, par inattention ou par paresse, on se retrouve à simplement oublier ou sous-estimer une partie prenante du projet. Elle finit par réapparaitre et on se retrouve alors avec un projet dont le scope est à revoir, car cette partie prenante a aussi des besoins et en général, ils sont distincts. Il faudra aussi composer avec un coût et des délais qui sont également à revoir et une acceptation, par cette partie prenante, pour aller en production qui est loin d’être gagnée et qui met donc le projet très à risque. On peut continuer comme cela longtemps mais je suis sûr que cela rappelle à tout un chacun des histoires vécues peu drôles.

L’absence des TI lors de la définition des projets

Les TI sont de nos jours une partie prenante quasi-incontournable peu importe les projets même strictement affaires. La préparation des projets devrait donc toujours inclure leur présence. Ce qui n’est pas toujours le cas. Et parfois parce que les TI eux-mêmes se sont exclus en disant que leur rôle en est un de livraison. En se mettant en position d’attente que tout a été défini, ils héritent d’un bébé en mauvaise santé et de la responsabilité qui va avec.

Les TI sont de nos jours une partie prenante quasi-incontournable peu importe les projets même strictement affaires.

Les TI devraient toujours se battre pour une place, ou un siège si vous voulez, à cette table, si ce n’est la leader. S’ils doivent hériter de l’exécution d’un projet, ils devraient absolument s’assurer non seulement que l’idée d’origine est claire mais aussi que le business case se tient, que la solution est la bonne faute d’être la meilleure et qu’elle répond bien aux contraintes de l’organisation globale et du département TI.

Ces projets aux problèmes de croissance

En plus de tous les problèmes qui ont été créés lors de la phase de définition des projets et qui sont passés inaperçus, donc véhiculés à la phase suivante, la phase de réalisation va s’assurer d’en créer elle aussi. Nous disposons de méthodologies de plus en plus évoluées et des ressources humaines de plus en plus qualifiées mais les problèmes, malheureusement, font partie de la réalité d’exécution des projets dans les technologies de l’information. Sans distinction de méthodologie aucune d’ailleurs. Il est vrai cependant que les proportions de projets à problèmes est légèrement plus faible avec Agile, quand les projets sont plus petits. Aucun projet n’est à l’abri d’une séquence d’évènements qui pourraient le mettre en danger. La réalité de l’échec des projets est souvent très complexe. Comme chacun sait il existe quelques indicateurs qui permettent de dire qu’un projet va mal mais ces indicateurs ne disent rien sur ce qui ne va pas bien. Les raisons sont simples, et les recherches sont formelles, c’est parce que, en général, les facteurs pour lesquels la situation s’est dégradée sont multiples et pour compliquer les choses, ces facteurs interagissent ensemble et s’influencent souvent les uns les autres intensivement. Ce qui fait du problème une espèce de cible à géométrie variable. C’est ce qui a tendance à tromper l’œil non averti ou non expérimenté et amène à corriger le mauvais problème.

Réhabiliter un projet soi-même ?

Ce qui est curieux, c’est que, quand des problèmes arrivent dans un projet, il est courant de constater que les organisations pensent que n’importe qui peut s’en occuper, réhabiliter un projet à dérive. On pense qu’il s’agit de quelques ajustements et que les choses rentreront dans l’ordre sans prendre le temps de bien comprendre ce qui est en train de se passer ou sans s’assurer que la ou les personnes qui s’en occupent font peut-être partie du problème. On essaye toute sortes de manipulations, souvent au hasard, et quand on commence à reconnaitre que c’est difficile, il arrive souvent que le projet est rendu trop proche de l’iceberg pour pouvoir l’éviter. Pour maximiser les chances d’être capable de le faire soi-même, l’idéal serait de détecter très tôt la dérive d’un projet ce qui donnera à l’équipe en place le temps de s’occuper du problème avant qu’il ne devienne complexe. Car si la situation se complexifie, il vaut mieux faire affaire avec des spécialistes.

L’idéal est de détecter très tôt la dérive d’un projet pour donner à l’équipe en place le temps de s’en occuper avant que le problème ne devienne complexe

Il y a certains reflexes qui pourraient être développés par les CIOs pour se faire une idée de la situation rapidement sans avoir à consentir un investissement trop grand en temps. A titre d’exemple, quelques questions qu’il serait utile de poser de temps en temps, comme ça en passant, pourraient donner des indications de ce qui se passe, comme les suivantes qui pourraient être introduites dans les revues régulières :

• Quelle est la dernière fois que le plan ou même le « Business Case » a été mis à jour ? S’il y a longtemps, il y a lieu de noter ça. Quelle est la nature et la fréquence de communication vers ou entre les parties prenantes du projet ? S’il n’y en a pas ou peu, vous avez une raison supplémentaire de vous intéresser au projet. Est-ce que l’assurance qualité est indépendante ? Votre intérêt devrait être encore plus grand en cas de réponse négative.
• Si travailler de longues heures devient la norme, s’il y a un roulement important dans l’équipe, s’il y a une attitude agressive et/ou sur la défensive envers tout ce qui est extérieur au projet et qui pose des questions (gestionnaires, consultants, audit, etc.) et/ou s’il n’y a pas de plaisir à travailler sur le projet, alors approchez vous encore plus car ce n’est pas bon signe.
• Alors demandez à arrêter le projet quelques temps pour regarder la situation, même si l’intention n’est pas de le faire. Si la réponse est : « nous ne serons jamais capable, dans ce cas, de rencontrer les échéances prévues » alors, inquiétez-vous très sérieusement et faites faire un diagnostic. Au pire ça vous rassurera.

Le faire faire ?

Réhabiliter un projet qui déraille n’est pas de l’ordre de la gestion de projet mais plutôt de la gestion de crise appliquée à la gestion de projet.

Faire soi-même le diagnostic de la situation ou même de réhabiliter un projet est possible, mais faire affaire avec un spécialiste est toujours préférable quand c’est sérieux car les projets qui déraillent ne sont plus vraiment de l’ordre de la gestion de projet. Ils tombent plutôt dans une catégorie très différente. Ils tombent dans la discipline de la gestion de crise appliquée à la gestion de projet. C’est un tout autre domaine dans lequel les approches sont différentes, les réflexes sont différents, les priorités sont différentes et les qualifications aussi. Cela requiert une connaissance de la gestion de projet aussi bien sûr, mais surtout pas uniquement ça.

La récupération des bénéfices

C’est ainsi que le CIO disposera des arguments qui démontrent son impact positif sur l’organisation et son efficacité

Un autre domaine très négligé, pourtant présent depuis longtemps dans la sphère des projets, est celui de la récupération des bénéfices. Bien des projets sont menés à bien, leur fin est célébrée, à juste titre, mais personne ne se préoccupe de s’assurer par la suite que les bénéfices évalués et calculés et promis sont bien récupérés ou planifié de l’être. Comme si cela se ferait tout seul. Comme par magie. Quelquefois ça arrive. Et quand c’est le cas, en général, c’est une récupération du minimum, au hasard et sur une très longue période de temps. Pourquoi ne pas développer et mettre en place une stratégie ou à tout le moins une démarche ou un plan pour s’assurer de récupérer tous les bénéfices et pas seulement ceux qui sont immédiats et qui croisent notre chemin presque par miracle. C’est encore un domaine qui tombe sous la responsabilité du CIO. Pourquoi? Parce que c’est lui qui rendra des comptes sur la transformation requise dans l’entreprise. D’ailleurs c’est ainsi qu’il disposera des arguments qui démontrent son impact positif sur l’organisation et son efficacité.

Auteur : Waheb Chebel, Gestionnaire de projets, auteur, conférencier.

Chebel Solutions Inc.

*CIO : Chief Information Officer, responsable du département des technologies de l’information