Le Bat Phone : livre blanc

Le titre de ce livre blanc fait référence à l’utilisation immodérée du « Bat Phone » par le commissaire Gordon chaque fois que la ville de Gotham City se trouvait dans une situation désespérée (dans la série TV des années 1970 « Batman »).

Ce livre blanc fait partie de notre collection « Depuis les tranchées ». Il fait référence à Batman pour illustrer comment, lors d’une implémentation EPM, il peut nous arriver de souhaiter avoir accès à un « Bat Phone » au moindre problème. Il évoque également les nombreuses manières d’éviter de se mettre en difficulté en cours d’implémentation.

Pour télécharger la version Word de ce livre blanc, voir Le Bat Phone.

Pour consulter d’autres livres blancs, voir les livres blancs « Depuis les tranchées ».

Le Bat Phone

La série originale « Batman » est sortie à la télévision en 1966. Bien qu’elle ne s’est étendue que sur 120 épisodes, son influence culturelle fut telle que nous en ressentons toujours les effets. Dans le monde de Batman et Robin (joués par Adam West et Burt Ward), Batman pouvait, grâce à la Batmobile, le Batboat, le Batplane et la Batcave trouver une solution à tous les problèmes. Si vous vous trouviez dans une situation délicate, il suffisait de décrocher le Bat Phone pour que Batman vienne vous sauver.

Image représentant un Batphone rouge (de la série télévisée « Batman »)

À chaque épisode, le commissaire Gordon devait appeler Batman avec le Bat Phone pour le sortir de situations délicates. En 22 minutes (sans compter les publicités), les méchants étaient vaincus et Gotham City retrouvait la paix.

Dans Batman, toutes les solutions avaient une forme de chauve-souris. Les menottes ressemblaient à des chauves souris La ceinture multifonction aussi. Même le grappin n’était pas en reste. Mais le Bat Phone, à ma grande surprise, était tout à fait normal. C’était un téléphone rouge à cadran. Le cadran était d’ailleurs superflu étant donné qu’il ne pouvait contacter qu’un seul endroit : La Batcave.

Toutefois, je ne suis pas là pour raviver la nostalgie des téléphones à cadran ou des anciens épisodes de Batman. Le Bat Phone est à la retraite depuis 40 ans mais, chaque jour, des personnes appellent les conseillers EPM dans l’espoir que quelqu’un viendra à leur aide.

Les méchants sont désormais nombreux et variés. Certains sont techniques. Pour les vaincre, il faudra procéder à une mise à niveau d’une version x vers une version y. Certains sont architecturaux. Leurs systèmes EPM internes doivent pouvoir entrer en contact avec le monde extérieur. Certains sont culturels. Dans ce cas, ce sont les utilisateurs qui refusent d’utiliser le système. Certains sont procéduraux. Le processus qu’ils utilisent ne semble pas produire les résultats escomptés.

Dans tous les cas, le défi que l’équipe de conseillers doit relever est le même : « Pouvez-vous régler cela en 22 minutes ? »

Aussi étonnant que cela puisse paraître, il s’agit d’une situation dans laquelle se retrouvent la plupart des utilisateurs d’EPM : ils ont besoin d’une aide d’urgence pour sortir d’une situation délicate. Il s’agit souvent d’une urgence qui devait déjà être résolue. Les personnes qui passent ces appels (plusieurs par semaine) ne sont pas pour autant simples d’esprit. Il s’agit souvent de gestionnaires très intelligents, capables et chevronnés.

Bien évidemment, le Bat Phone n’existe pas. Comme j’aimerais qu’il y en ait un. Je l’utiliserais pour résoudre toutes sortes de difficultés personnelles. Ainsi, les personnes qui passent ces appels sont rarement satisfaites par les réponses qu’elles reçoivent. Prenons donc quelques instants pour comprendre comment ces personnes se retrouvent dans une position à ce point inconfortable qu’elles doivent décrocher le téléphone rouge, et comment éviter d’être l’une d’elles.

Mise en difficulté

Commençons par voir comment les gens se retrouvent en situation difficile lors d’une implémentation EPM. Il existe quelques causes courantes :

  • Sous-estimation de la difficulté    C’est de loin l’erreur la plus courante dans le cadre d’un déploiement EPM. Je ne veux pas dire que tout déploiement est nécessairement de grande ampleur et difficile. Ce n’est certainement pas toujours le cas. Toutefois, peut-être en raison d’une propension à se bercer d’illusions, il est extraordinairement fréquent que l’on sous-estime les efforts nécessaires pour bénéficier des avantages d’un déploiement EPM. La première erreur de sous-estimation réside dans le choix de la cible. Certaines personnes considèrent qu’un projet est réussi quand l’outil est installé. C’est évidemment faux. Certaines personnes considèrent que la cible est la première utilisation de l’outil ou le premier rapport qu’il produira. C’est également faux. La cible, c’est la résolution de tous les problèmes pour lesquels les outils EPM ont été choisis. Cela signifie que la culture a changé, que la formation est terminée, que la solution est utilisée en production, que les outils fonctionnent et que les données sont disponibles. Cela peut sembler beaucoup mais, si vous manquez cet objectif ne serait-ce que d’un doigt, c’est comme si vous n’aviez rien fait (disons presque rien...).

  • Surestimation de l’aspect technique    Ceux d’entre nous qui travaillent dans le secteur des technologies savent mieux que quiconque que nous sommes les premiers coupables à cet égard. Pourtant, pour une raison quelconque, il est difficile de résister à la tentation de croire que la disponibilité d’une technologie signifie que le problème est résolu. Nombreuses sont les organisations que nous visitons, qui nous disent quelque chose comme : « Nous avons pourtant installé Project Server. Comment se fait-il que notre personnel soit toujours surchargé ? » Comme nous avons coutume de le dire, le bon fonctionnement d’un système de gestion de projet d’entreprise repose sur un assemblage judicieux de personnes, de technologies et de processus, additionné d’une dose généreuse de gestion des changements pour faire bonne mesure. Cela ne se produit pas automatiquement à l’arrivée du DVD contenant le logiciel.

  • Non-implication de l’encadrement    Cela aussi se produit très souvent. Après tout, les personnes qui comprennent le mieux les avantages d’un système de gestion de projet d’entreprise sont très probablement celles qui s’efforcent d’analyser les énormes quantités de données provenant d’un environnement comptant un grand nombre de projets et ressources. La gestion de projet d’entreprise est particulièrement populaire parmi les organisations désireuses de concilier un ensemble complexe de priorités conflictuelles et une combinaison pléthorique de compétences et d’expériences. Vous pourriez penser que les cadres supérieurs sont naturellement impliqués dans un tel projet, mais ce n’est souvent pas le cas. Bien que la difficulté de modifier la culture d’entreprise pour passer d’une mentalité de projet unique à une mentalité de projet d’entreprise soit pratiquement insurmontable sans leur aide, les cadres supérieurs sont beaucoup trop souvent évités par crainte qu’ils soient incapables de mesurer les efforts nécessaires pour aller jusqu’au bout d’un déploiement EPM.

  • Établissement de plannings irréalistes    Nul ne souhaite qu’un déploiement EPM nécessite beaucoup de temps. Et il est courant d’espérer que le projet puisse aboutir en quelques jours ou semaines, plutôt qu’en plusieurs mois, comme c’est le plus souvent le cas. Une autre difficulté assez répandue est qu’il soit plus difficile d’obtenir de ressources pour un projet « interne » tel un déploiement EPM que pour un projet commercial ou axé sur la clientèle. Pour ces raisons (entre autres), il est fréquent qu’un échéancier de projet planifie des besoins en ressources déplorablement insuffisants.

  • Non-application d’une gestion de projet au système de gestion de projet    Si vous avez lu certains de mes écrits, vous êtes probablement déjà conscient de ce problème. Les responsables de projet sont souvent atteints du syndrome du « cordonnier mal chaussé ». Le résultat est une absence fréquente, pour leur propre projet, de charte de projet, de budget approuvé, d’échéancier suivi, de ressources dédiées et de tout l’attirail commun à tous les autres projets qu’ils gèrent.

À quoi s’attendaient-ils ?

Bref, voilà comment se mettre en difficulté. Les avantages que l’encadrement attend du déploiement d’un système EPM sont généralement directement associés à des problèmes d’entreprise. C’est la promesse de résoudre ces problèmes qui amène l’encadrement à approuver les dépenses consacrées aux logiciels, au matériel, à l’infrastructure et peut-être même aux services. Les problèmes les plus courants vous sembleront peut-être familiers :

  • Surcharge des ressources    Il n’est pas toujours facile de déterminer ce que font les ressources, mais il est fréquent de constater qu’elles sont surchargées. Un problème plus complexe est de constater que certaines ressources sont surchargées tandis que d’autres sont sous-utilisées, ce qui trahit souvent une discordance entre la disponibilité et les besoins de compétences et d’expérience.

  • Non-respect des délais d’exécution des projets critiques    Il devrait être évident que les projets critiques doivent s’achever au moment planifié, mais la vie semble en décider autrement. Cela peut être dû à des conflits de besoins en ressources, au choix d’un trop grand nombre de projets nécessitant des compétences identiques, ou à une mauvaise hiérarchisation. Les organisations estiment parfois qu’il s’agit d’une incompétence du responsable de projet. Toutefois, dans un environnement matriciel comprenant plusieurs projets et plusieurs départements, le problème est plus probablement de nature organisationnelle.

  • Non-respect des budgets des projets    Ce qui vaut pour l’échéancier vaut également pour les coûts. Dans le secteur de la haute technologie comme dans de nombreux autres secteurs, la composante la plus variable du coût d’un projet est la quantité de travail nécessaire à sa réalisation. L’utilisation des mêmes personnes pendant beaucoup plus de temps que prévu alourdit les coûts. Un nombre stupéfiant de projets de nature intellectuelle ne sont pas suivis. Ils sont planifiés, mais leur coût réel n’est pas consigné.

  • Concurrence plus rapide dans la réalisation de projets    Dans une économie concurrentielle, la vitesse de mise sur le marché détermine la survie ou l’oubli. Par conséquent, pour de nombreuses organisations, il est essentiel de s’assurer que leur gestion de projet soit au moins aussi efficace que celle de la concurrence.

  • Absence de visibilité quant à l’emploi du temps des ressources d’un projet, ou impossibilité de savoir le temps consacré à chaque projet    Parfois, l’absence de réponse est pire qu’une mauvaise réponse. C’est particulièrement vrai si vous êtes cadre supérieur. Si vous savez que les résultats sont mauvais, vous pouvez mobiliser vos compétences et les ressources à votre disposition pour agir. En revanche, si vous savez que quelque chose ne va pas, mais êtes incapable de déterminer ce dont il s’agit, vous êtes paralysé. Vous n’avez aucun moyen de savoir que faire pour résoudre le problème.

Comment éviter de se mettre en difficulté ?

Vous n’avez pas envie de jamais vous retrouver dans une situation où vous auriez besoin d’un Bat Phone. Par conséquent, que pouvez-vous faire avec votre environnement EPM pour être certain d’échapper à cette situation ?

Bon, tout ce que nous avons dit dans la première section est évident :

  • Effectuer une bonne estimation

  • Ne pas considérer un déploiement EPM comme un projet purement technique

  • Impliquer l’encadrement supérieur dès le début

  • Établir un échéancier plausible et le confronter à la réalité en le comparant à d’autres projets accomplis dans votre secteur

  • Créer un échéancier et une charte de projet, et procéder comme vous le faites d’habitude pour vos autres projets

Que pouvez-vous faire d’autre ?

Tout d’abord, démarrer le projet en vous disant qu’à l’avenir, vous voudrez utiliser le Bat Phone. C’est le cas. Vous pouvez budgétiser une assistance sans savoir encore ce que vous en ferez. Nous conseillons à nos clients de budgétiser entre 10 % et 20 % en prévision de « besoins non alloués ». On nous demande toujours : « À quoi cela peut bien servir ? ». Et nous répondons invariablement : « C’est vous qui nous le dires plus tard. ». Bien souvent, ce budget n’est pas entièrement utilisé. En revanche, il est très fréquent qu’il soit partiellement utilisé. Disposer d’un expert compétent et d’un budget pré-alloués pour votre projet pourra faire une énorme différence dans le futur.

Commencez par vous convaincre que le plan et les ressources peuvent changer. À cet égard, en relation avec la gestion de projet, j’aime à citer Napoléon Bonaparte qui disait : « Aucun plan ne survit au contact de l’ennemi ». C’est également vrai des plans de déploiement EPM. Étant donné qu’une implémentation peut durer plusieurs mois, la probabilité que certaines personnes soient remplacées est considérable. Il faut donc prévoir une redondance.

Les systèmes EPM évoluent. Quand il est question d’application d’entreprise, on songe fréquemment au « coût total de possession ». Je pense qu’il faut inclure dans nos plans de projet EPM le cycle de vie total de l’application. Avez-vous songé à la version d’un outil que vous vous préparez à implémenter ? Avez-vous pensé aux autres outils dont il dépend ? Qu’en est-il de la mise à jour ou à niveau régulière de ces outils ? Les avez-vous personnalisés ? Qu’en est-il de la formation personnalisée ? Avez-vous réfléchi à la manière de migrer ces éléments vers une nouvelle version si vous en déployez une ?

Planifiez aussi une redondance de vos experts. Si vous ne disposez que d’un seul consultant, que se passera-t-il dans quelques mois quand vous passerez à une nouvelle phase de votre implémentation ou introduirez un nouveau membre clé de votre équipe ? Ce consultant sera-t-il disponible ? (Les consultants passant d’un projet au suivant, la réponse est souvent, « non ».) Si vous travaillez avec une société de conseil, l’avez-vous interrogée sur la manière dont elle préserve le travail de son personnel afin que d’autres personnes puissent le reproduire si nécessaire ?

Mettre les choses par écrit

L’une des difficultés les plus courantes et les plus faciles à surmonter est l’indigence de la documentation. Il s’agit de l’aspect le plus facilement négligé. Pourtant, l’existence d’une telle documentation peut faire la différence entre consulter une référence écrite et saisir le Bat Phone. Il ne suffit pas d’écrire un document et de le glisser dans une tiroir. Les documents doivent être actualisés en permanence, et votre processus EPM devrait s’y référer dans le cadre d’un processus de révision régulier. Voici quelques documents qui me paraissent essentiels dans un environnement EPM :

  • Étude de cas    J’ignore pourquoi les études de cas sont souvent jugées rébarbatives. Toujours est-il que c’est un élément souvent négligé, alors qu’il est l’essence même de la raison pour laquelle vous avez un environnement EPM. L’étude de cas énonce les avantages organisationnels, soit ce que l’organisation attend du système EPM. Lorsque nous recevons un appel Bat Phone, l’une des premières questions que nous posons est la suivante : « Qu’est-ce que le système est supposé faire ? ». Nous n’interrogeons pas uniquement l’administrateur. Nous interrogeons également l’encadrement, les utilisateurs et les bénéficiaires du système. La réponse varie selon la partie interrogée. Cela résulte du fait que les principes d’origine se sont perdus dans l’oubli.

  • Rôles et responsabilités    La définition ultime des rôles et responsabilités consiste souvent à désigner des personnes. Or, le rôle qu’elles jouent dans le système EPM est rapidement perdu de vue. Disposer d’un document définissant les rôles et responsabilités vous permettra d’ajuster les paramètres déterminant la répartition des tâches dans le processus EPM, au fur et à mesure des changements de personnel ou même de structure organisationnelle.

  • Guide et organigramme de processus    En ce qui concerne les guides de procédures, ces éléments sont souvent oubliés. Un manuel de procédure fournit aux utilisateurs des instructions relatives à diverses opérations, mais aucun contexte ne leur permet d’en comprendre l’importance ou l’utilité de leurs résultats. Un guide de processus et, surtout, un organigramme permettront aux futurs gestionnaires de comprendre l’utilité du système, et de l’adapter plus facilement à l’avenir.

  • Critères de sélection du système    Lorsque vous choisissez un système EPM ainsi que d’éventuels outils tiers, vous devez songer à permettre aux futurs utilisateurs de comprendre le fondement de votre décision. Nous avons découvert, dans certaines organisations, quelque 5, 7, voire 10 ans après le déploiement d’un système, divers outils qui y étaient associés, mais dont nous ne comprenions pas la raison d’être. Il nous semblait beaucoup plus simple de s’en passer. Les motifs de ces choix sont souvent introuvables. Certains client passent des années à faire des opérations extrêmement complexes, alors qu’ils pourraient se simplifier la vie en acquérant des versions plus récentes d’outils existants. Ils ne peuvent pas facilement décider de changer d’outil ou d’en acquérir une version plus récente, car ils ne savent plus pourquoi, plusieurs années auparavant, ils ont choisi de faire telle chose de telle manière.

Il n’y a définitivement pas de Bat Phone.

Quand je dis cela, c’est comme si je disais que les fées ou le Père Noël n’existent pas. Ce n’est pas une bonne nouvelle. Mais le Bat Phone n’existe pas. Je suis néanmoins convaincu que la seule absence de cet engin magique n’empêchera personne de m’appeler demain pour me demander de terrasser le prochain ennemi public de Gotham City. Si vous rencontrez des difficultés et ressentez le besoin d’appeler un expert, voici quelques recommandations :

  1. Écoutez les conseils que l’on vous donne. Il est absurde de payer un expert pour vous conseiller, puis de décider que vous en savez plus que lui. Si vous demandez conseil à un expert, tâchez au moins d’écouter ce qu’il vous dit et d’en tenir compte. Batman aurait tôt fait de laisser tomber le commissaire Gordon si, après chaque appel, ce dernier avait fini par lui dire : « Maintenant que vous êtes là, faites comme mes policiers. »

  2. Batman pourrait le faire en 22 minutes, mais vous ne le pouvez probablement pas. Si vous appelez un expert, laissez-le vous dire le temps nécessaire pour résoudre votre problème. Vous pouvez toujours décider de ne rien faire, mais vous devez savoir qu’un problème de déploiement EPM se règle rarement en quelques minutes. Après tout, Batman devait tout arranger en 22 minutes parce que 8 minutes étaient consacrées à la diffusion de publicités indispensables.

  3. Le commissaire Gordon n’a jamais soufflé à Batman la solution. Il se contenait de lui exposer le problème. Nous recevons trop souvent des appels d’administrateurs EPM paniqués, persuadés qu’il nous suffit d’appliquer un correctif, de rédiger un rapport et de former une ou deux personnes. J’ai coutume de les écouter patiemment, puis de leur demander de décrire le problème avec autant de soin qu’ils m’ont exposé la solution. Avant de décrocher le téléphone pour appeler un expert, commencez par réfléchir au problème que vous voulez mettre sur la table.

Conclusion

Vous devez vraiment utiliser le Bat Phone. Informez-vous. N’interrogez pas qu’un seul expert conseil, et ne vous contentez pas d’une seule solution possible. Demandez à vos collègues ou à d’autres personnes de votre secteur d’activité s’ils connaissent quelqu’un pouvant répondre à un appel Bat Phone, et discutez avec au moins deux d’entre eux. Une bonne confrontation à la réalité est de comparer les solutions proposées par au moins deux experts. Batman était certes stupéfiant, mais il existe d’autres super-héros.

À propos de l’auteur

Chris Vandersluis est le président et le fondateur de HMS Software. Basée à Montréal (Canada), l’entreprise est un partenaire Microsoft Certified Partner. Diplômé en sciences économiques de l’université McGill, Chris a plus de 30 ans d’expérience dans l’automatisation des systèmes de gestion de projets. Il est membre du Project Management Institute (PMI) depuis de nombreuses années et a participé à la création des chapitres du Microsoft Project Users Group (MPUG) pour Montréal, Toronto et Québec. Il a publié des articles dans Fortune, Heavy Construction News, Computing Canada et PMNetwork. Il tient également une chronique régulière pour Project Times. Il enseigne la gestion de projets avancée à l’université McGill et intervient souvent lors d’événements organisés par des associations de gestion de projets en Amérique du Nord et dans le monde entier. HMS Software est l’éditeur du système d’horloge pour les projets TimeControl et est un partenaire Microsoft Project Solution Partner depuis 1995.

Vous pouvez contacter Chris Vandersluis à cette adresse : chris.vandersluis@hms.ca.

Pour consulter d’autres articles en lien avec la gestion des projets d’entreprise rédigés par Chris Vandersluis, rendez-vous sur le site EPM Guidance de HMS Software (http://www.epmguidance.com/?page_id=39).

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×