Piloter les projets d’infrastructure IT par la documentation

indispensable documentation projet

Avez-vous remarqué, comme moi, que le niveau des documentations fournies par les intégrateurs, fournisseurs de service et autres infogérants est de plus en plus bas ? Floues, basées sur le copier/coller, pas adaptées, pas didactiques, pas simples à lire par des exploitants.

Difficile de faire avancer des projets de cette façon, tout peut être remis en cause à tout moment, difficile de se poser, de prendre du recul, de réfléchir sans être dans le conflit avec ses équipes, ses clients et ses fournisseurs. Lire la suite

Déménagement IT : démonstration par l’absurbe

Dans nos activités liées aux déménagements (sièges d’entreprises, datacenters), il arrive quelquefois de rencontrer des entreprises qui ont du mal à en voir l’utilité de l’assistance, à comprendre notre rôle sur ces projets, allant jusqu’à nous confondre avec des entreprises manutentionnaires, preuve du décalage des points de vue de référence.

Pour briser la glace d’incompréhension, il m’arrive parfois de faire la démonstration suivante, par l’absurde. Je demande à mon interlocuteur d’imaginer qu’il déménage son PC de son bureau à son domicile, pour y faire du télétravail durable. Il a besoin d’un véhicule certes (le déménageur). Mais s’il ne prend aucune autre mesure, beaucoup d’applications ne fonctionneront pas sur son PC une fois connecté chez lui. Bien sûr ! est la réaction habituelle. Pourtant, vous y avez déjà accès à Internet, WiFi…

Pour faire court, nous sommes des ingénieurs qui menons les projets nécessaires pour que les postes de travail ou serveurs informatiques fonctionnent dans leur nouvel environnement (à votre domicile dans notre analogie). Dans le même temps, nous définissons / sélectionnons / faisons les recettes des installations et équipements du nouveau site.

Il est possible de faire ce travail par soi-même. Mais c’est faire peu de cas de l’expérience accumulée par la répétition des chantiers. A ce compte là, chacun peut être maçon pour construire sa maison.

Mûrir une décision à plusieurs: se voir souvent pas longtemps

Dans le cadre de nos missions, nos clients sont fréquemment amenés à faire des choix de solutions pour leurs investissements. La décision d’achat est en général plus stressante pour l’acheteur que pour le vendeur, surtout si cette décision est solitaire : « Et si je me trompais ? »

Une méthode connue, prônée par saint Ignace au 16ème siècle et tout à fait efficace pour asseoir une décision, est de la prendre dans sa tête, puis de voir si on se sent en paix avec, en particulier avec les conséquences de cette décision.

En entreprise, la décision est souvent collégiale, et demande l’assentiment de plusieurs personnes. Nôtre rôle de Conseil est de préparer les termes de l’évaluation et de la documenter, parfois de jouer un rôle de miroir dans la décision. Mais nous ne pouvons jamais prendre la décision à la place de notre client : outre que ce serait un abus de position, il y aurait un fort risque de déresponsabilisation du signataire, ce qui est au final très dommageable pour l’entreprise.

Une décision, si elle est importante et structurante, se mûrit. Nous sommes parfois inquiets de décisions prises sur la base de dossiers, qui ont été examinés une fois, puis mis de côté jusqu’au jour où la décision doit être prise. Dans l’intervalle, les décideurs, pris par leur quotidien, ne reviennent pas sur ce dossier, et se trouvent au final mal armés le jour de la « grande réunion » de décision. Ce qui entraîne fréquemment de sages reports, mais a aussi pour conséquence, parfois néfaste, de ralentir l’action.

Une recommandation que nous avons est de programmer (nous disons bien programmer à l’avance, car sinon le quotidien prend le dessus) de petites réunions courtes pour en parler. C’est en fait en en parlant régulièrement et pas longtemps que le recul se prend, et que le bon sens et/ou l’audace, partagées, prennent racine. A petits coups de points de vue échangés, d’enjeux identifiés, de mesures anticipées, de corrections progressives, la décision se prend dans les esprits. Et le grand jour, c’est déjà presque réglé !

Les marathons de l’IT

Il y a une semaine, j’ai terminé mon premier marathon. Durant ma récupération, il m’est apparu que l’expérience, aussi forte qu’elle soit, n’est pas si différente de nombreux projets IT.

Pourquoi se lancer dans ce défi ?

Mon objectif personnel était de retrouver la forme. En 2000, j’avais couru les 20 km de Paris en 1h40 mais depuis, chaque année apportait sa petite masse de « confort ». Si mes enfants étaient des garçons, ils commenceraient à me chahuter facilement au football ou autre activité sportive. Le marathon de Paris qui passe presque sous mes fenêtres représentait aussi un certain rêve qu’il vaut mieux essayer d’atteindre avant la cinquantaine.

Dans l’IT, le constat est souvent similaire même si les apparences peuvent être plus trompeuses puisque physiquement les équipements ne grossissent pas ou ne rouillent pas. Derrière les façades des serveurs ou des PC, les licences ne sont plus à jour, plus aucun développeur ne maintient l’application chez le fournisseur, des comptes utilisateurs restent dormants, etc. Oserez-vous rêver d’un SI à la pointe ?

Mais les freins sont nombreux…

Les freins sont multiples, y compris et surtout dans l’environnement proche. Pour le marathon, votre famille craint pour vous la crise cardiaque : tu ne cours plus depuis 10 ans ! ». Accessoirement, elle va devoir allouer un budget temps à l’activité. Ou tout simplement, elle ne vous croit pas capable de relever ce défi. Vous-même, à peine êtes-vous inscrit, le doute vous gagne et la ligne d’arrivée semble s’éloigner. Un petit secret des organisateurs de marathon est qu’ils annoncent le nombre d’inscrits et de « Finishers » (l’anglais triomphe ici aussi) mais peu souvent le nombre de partants, car c’est entre l’inscription et le départ que les défections sont les plus nombreuses.

Dans l’IT, il y a toujours quelques systèmes « critiques » qui justifient de continuer à ne rien changer. Aussi, passé l’inscription d’une envie, une idée à un « schéma directeur », « programme de transformation », combien de projets IT prennent réellement le départ ?

La préparation

Le constat qui permet de franchir cet obstacle consiste à se rendre compte que vous n’êtes pas le premier à relever ce même défi. Dès que vous prenez la peine de chercher, vous trouvez nombre de livres, de sites web dédiés, de coaching/programme de préparation à un marathon. Outre le plan d’entraînement indispensable qui s’appuie sur des retours d’expérience, il ne faut pas non plus oublier les équipements : vêtements spécifiques, montre multifonction sont autant « d’accessoires » qui sont tout sauf superflus. D’ailleurs, l’ensemble de ce dispositif est un investissement plus important que l’inscription elle-même (la course reste cependant un des sports les plus abordables).

Dans l’IT, cette phase de préparation et d’équipements prend d’autres formes comme des études préalables, des matériels de qualification/test, de la formation, des pilotes. Les projets qui réussissent investissent clairement dans leur succès.

La logistique

Au passage, il ne faut pas sous-estimer l’aspect « commodité » des phases de préparation. Je n’aurais pas envisagé cette aventure si les locaux de Setec à Paris n’étaient pas dotés d’une salle de sport avec douches et si le jardin des plantes, à deux pas, ne m’offrait la possibilité de m’entraîner une heure en toute facilité, deux midis par semaine. Avis aux ingénieurs qui veulent candidater chez Setec.

Dans l’IT, étonnamment, on insiste à mon avis insuffisamment sur les outils qui facilitent le déroulement aisé des projets : partage de fichiers pour réviser efficacement des documents, visio et web-conférence pour mobiliser des experts à distance, salle projet pour visualiser l’avancement projet (techniques de management visuel des méthodologies Lean), des solutions aisées de VPN et de prise de contrôle à distance, PC performants.

marathon-chaussure

Le mur

Le coureur préparé arrive donc au départ du jour J en ayant accumulé 200 à 300 km de courses (point de différence notable avec l’IT, le candidat marathonien ne peut outsourcer cet effort). Comme tout projet bien préparé, la conséquence immédiate est que les deux premiers tiers de l’effort se déroulent sans incident ou douleur particulière. Même pas un caillou dans la chaussure. Vous prenez le temps de vous arrêter au ravitaillement pour boire, manger, contrôler votre tempo. Bref vous gérez. En attendant d’arriver au-delà des 30 km, zone que vous n’avez jamais explorée dans les entraînements hebdomadaires et que tous les marathoniens racontent jalonnées de coups de pompe.

Effectivement, à ce stade, au premier faux plat (le qualificatif de côte serait excessif), vous éprouvez une difficulté insurmontable à continuer inlassablement à mettre un pied devant l’autre en courant. C’est là que vous comprenez un détail de l’organisation. Sur votre dossard, outre votre numéro, est inscrit votre prénom (et non votre nom) : les spectateurs qui voient ceux qui flanchent peuvent les interpeller directement pour les relancer (merci à ceux et celles qui ont trouvé les mots le long de la route pour m’avoir aidé à repartir à chaque fois).

Dans un projet IT, le support du management est crucial dans ces phases où l’arrivée n’est plus très loin mais semble inatteignable pour un obstacle quelconque et quelquefois imaginaire. D’autant que les cris de l’environnement ne sont pas tous au soutien.

La récupération

Même bien préparé, un marathon laisse des traces dans l’organisme. Il ne viendrait à l’idée de personne de se programmer une autre compétition dans la semaine qui suit. Pourtant, c’est ce que font nombre d’organisations avec leur IT comme l’a remarqué Serge dans son billet Prenez le temps de clôturez vos projets, vous serez plus efficace pour le suivant.

Même si comparaison n’est pas raison, ne soyez pas étonné si, dans les mois qui viennent, les analogies dont j’affectionne l’emploi sont plus sportives. Et bonne route pour les projets IT.

 

Prenez le temps de clôturer vos projets, vous serez plus efficace pour le suivant !

« La nature a horreur du vide » dit-on. De même certains patrons ont horreur de sentir que leurs équipes ne sont pas à fond. Leur impatience est presque vue comme une vertu ! A peine a-t-on terminé un projet qu’on demande au chef de projet de passer sur un autre. Pourtant un temps de recul serait souvent bénéfique pour capitaliser la richesse.

Le happening permanent, au contraire de créer de l’efficacité et de la productivité, détruit en fait souvent la richesse de l’entreprise. Les motifs d’appauvrissement sont connus, même si souvent ignorés :

  • On ne pousse pas les bénéfices du projet jusqu’au bout en s’arrêtant aux premiers fruits. Pourtant ceux qui suivent seraient obtenus à moindre coût, puisque l’effort principal a été fait.
  • La capitalisation de connaissances est mal réalisée : une partie part avec le chef de projet, qui lui-même n’a pas eu le temps de prendre du recul
  • Le risque d’érosion des progrès initialement obtenus augmente, car les exploitants et utilisateurs n’ont pas réellement intégré tous les bénéfices du nouveau système, et comment en tirer parti ; ils ont pris le bateau trop vite.

Je voudrais indiquer un motif plus caché, et pourtant réelle source d’appauvrissement : la lassitude des chefs de projet, et de leurs équipes.

Si on modélise l’énergie du chef de projet et de son équipe au cours de la vie d’un projet cela donne quelque chose comme cela :

Pour reprendre son souffle entre deux projets, le chef de projet, et ceux qui participent à ces projets, doivent avoir le temps de se retourner en arrière, de prendre conscience du chemin accompli, de faire le bilan, et de se dire qu’ils peuvent passer à autre chose. Bref, de faire le deuil ! C’est tout le sens de cette étape.

Si on ne laisse pas ce temps de capitalisation, les équipes n’ont pas le temps de reprendre de l’énergie, d’où un phénomène de lassitude. Cela se traduit par une idéalisation des projets anciens, un manque de créativité et d’enthousiasme, et une forme de résignation. On pourrait le représenter ainsi :

En bref, clôturer un projet, c’est laisser respirer la pâte, elle n’en sera que meilleure !!

 

Serge