Management

Les huit tueurs de productivité de votre DSI

Les mauvaises pratiques font dérailler les DSI, certaines sont particulièrement handicapantes (©Thomas Tucker on Unsplash).

Négligences ou mauvaises habitudes, les facteurs ne manquent pas pour tuer la productivité de votre DSI.

PublicitéIl existe deux types de tueurs pour votre productivité : les petites distractions qui vous empêchent de vous concentrer et les gros tueurs de productivité, ceux qui vous poussent à disperser du temps et des efforts aux mauvais endroits. Vous trouverez ci-dessous un aperçu de huit de ces pratiques, celles qui font dérailler votre DSI, et la manière d'ajuster vos efforts pour réussir.

1. Négliger d'affecter des priorités à vos projets stratégiques
L'informatique doit éteindre les incendies. Lorsque les serveurs bancaires en ligne tombent, c'est une urgence. Mais les situations de panique ont tendance à être rares. Ce qui domine, c'est plutôt le flot constant de questions et de demandes de changements de la part des utilisateurs. Les rendre heureux est un objectif louable, mais vous pouvez facilement être victimes d'une réflexion uniquement axée sur le court terme.
« La plus grande erreur de productivité que la plupart des responsables informatiques et des dirigeants font, c'est de ne pas parvenir à établir des priorités. De nombreuses DSI sont débordées par les tâches importantes à accomplir, depuis la maintenance de leurs applications et de leur infrastructure, jusqu'à la réponse aux pannes et aux problèmes », explique Alan Zucker, directeur fondateur de Project Management Essentials. « Plutôt que de prioriser le travail, la DSI continue d'assumer de plus en plus de projets. En augmentant continuellement leur nombre, celui des choses abouties diminue. La qualité souffre. Les professionnels hautement qualifiés et motivés en ressortent frustrés. »
En tant que responsable informatique, vous devez donner l'exemple en vous concentrant sur des projets de grande valeur. Sinon, votre entreprise ne progressera jamais dans ses objectifs stratégiques.

2. Mal gérer les promotions des techniciens
Lorsque les professionnels de l'informatique, venus de la technique, passent à la gestion, ils font face à un changement difficile. Les récompenses et les attentes auxquelles ils sont confrontés en tant que gestionnaire sont très différentes. Gary Davenport, ancien président de l'Association canadienne des DPI, a vu de nouveaux gestionnaires IT tuer la productivité en s'adaptant mal à leurs nouvelles fonctions.
« Les responsables informatiques qui passent par les échelons techniques sont habitués à être récompensés pour leur capacité à travailler à un niveau détaillé, avant d'être promus à des postes de management. Il n'est pas surprenant que les responsables informatiques puissent avoir du mal à faire la transition. Les signes avant-coureurs commencent par une incapacité à laisser de côté les détails techniques et en même temps une difficulté à remplir un vrai rôle de leader », explique Gary Davenport. « Pensez à ceux qui s'inquiétait de l'organisation des chaises longues sur le pont du Titanic en passant à côté d'un évènement plus important ! Ne soyez pas des « arrangeurs de chaises longues ».
Les DSI doivent aider leurs équipes à traverser cette transition. Reconnaître que les nouveaux responsables informatiques sont confrontés à une transition difficile et les aider en partageant certaines des leçons apprises en cours de route.

Publicité3. Négliger de développer votre réseau (humain)
Les réunions de travail sont comme un régime : trop peu ou trop nuit au succès de votre département. En tant que manager, vous avez une influence significative sur les réunions auxquelles vous participez. Certaines réunions sont essentielles à votre succès. « Nous vivons dans un monde très rapide, et vous êtes en train de parler loin d'un nouveau client, d'un nouveau fournisseur, d'un nouvel employé. Je consacre beaucoup de temps à parler aux gens, à assister à des réunions, à des événements et à lire. J'essaie de rencontrer 20 à 30 personnes chaque semaine », explique Denis Zhirovetskiy, président d'Adeptcore.
En tant que responsable informatique, adaptez cette philosophie à votre situation. Rencontrez régulièrement de nouveaux employés et parties prenantes potentielles d'autres parties de l'entreprise, ce qui produira des dividendes à long terme.

4. Négliger d'être à l'écoute pour toute l'entreprise
En tant que responsable informatique, comment devez-vous réagir lorsqu'un manager ou un cadre d'une autre unité vous demande un nouveau projet ou une nouvelle technologie ? La façon dont vous gérez ces demandes façonnera votre succès.
Pour Gary Davenport, les responsables informatiques doivent se concentrer sur les résultats plutôt que sur les commandes. « Ils doivent toujours se concentrer sur l'ajout de la valeur métier et non simplement sur la prise de commandes. Cela signifie d'être capable de vraiment comprendre la stratégie de l'entreprise et également d'être en mesure de traduire avec succès cette stratégie en résultats significatifs. En d'autres termes, concentrez-vous sur les résultats métier et non sur les activités ou l'informatique dans le détail pour y arriver. Bien que ce soit important, ce n'est plus votre rôle principal et cela peut mener finalement à un échec ».
Pendant des années, les responsables informatiques ont cherché à dépasser leur rôle de preneurs de commandes, celles que leur passent les métiers. Pourquoi est-ce que prendre des commandes de l'entreprise est un problème ? Si un directeur des ventes suppose « nous avons besoin d'une nouvelle application » et que l'informatique l'a fait sans discuter, les ressources de l'entreprise peuvent être gaspillées parce que les responsables informatiques n'ont pas recherché d'autres alternatives.

5. Ne pas donner la liste des succès chaque semaine
En technologie, nous réalisons des projets qui prennent souvent des semaines ou des mois à se développer. Le calendrier est encore plus serré lorsque vous travaillez avec des systèmes hérités. Ces grands projets peuvent être démotivants à court terme car la ligne d'arrivée est lointaine. Une partie de la réponse consisterait à définir des paramètres pour une semaine productive.
« Je garde un tableau Kanban dans mon bureau », explique Alan Zucker, Project Management Essentials. « Je mesure le nombre de tâches que j'effectue chaque semaine et je mesure ma productivité en fonction du nombre de celles qui sont dans la colonne « Terminé ». En utilisant le Kanban et en limitant le nombre d'éléments sur lesquels je travaille, je suis plus productif. En visualisant le travail et les éléments qui sont bloqués ou en attente d'une contribution de quelqu'un d'autre, je garde une trace de tout ce qui est en cours. »
La clé de l'approche d'Alan Zucker est de « limiter le nombre d'objets sur lesquels je travaille ». C'est plus facile à dire qu'à faire parce que vous devez dire non aux gens. La clé consiste à avoir un portefeuille de succès à court et à long terme.

6. Ne pas trouver un équilibre entre productivité à court et à long terme
Vos équipes sont sensibles au succès. Mais laissés à eux-mêmes, les développeurs et autres professionnels peuvent se concentrer sur les tâches urgentes à court terme. Celles qui fournissent un sentiment de satisfaction rapide, mais ne peuvent pas impacter votre stratégie à plus long terme.
« Lorsque j'ai travaillé sur une implémentation de nouvelle technologie pour un client, deux employés ont été formés sur l'outil mis en place. L'un d'entre eux a été complètement motivé en quelques mois, effectuant des changements de configuration quotidiens, alors que l'autre après un an avait à peine pu le faire. C'est ici que la motivation, le contexte et les compétences entrent en jeu », explique Felix Acosta, gestionnaire principal auprès du DPI de KPMH Canada.

7. Ne pas avoir ajusté les prévisions initiales du projet
Savoir quand remettre en question les projections de votre équipe est une compétence essentielle dans la gestion informatique. Si vous la challengez trop souvent, votre équipe peut avoir l'impression de ne pas avoir votre confiance. Si vous ne la contestez pas du tout, c'est peut-être que vous faitr es des promesses irréalistes à vos hauts dirigeants. Jason Swett, un consultant en ingénierie et créateur de CodeWithJason.com, a appris cette leçon à la dure.
« En 2015, j'ai travaillé dans une agence où nous construisions une plate-forme de formation à la vente pour une entreprise de technologie bien connue. Avant, l'agence avait confié aux ingénieurs juniors des tâches critiques. Six mois s'étaient écoulés et l'agence n'avait pas de produit fonctionnel pour montrer au client. Quelques semaines avant la date limite, nous avons discuté si nous pouvions réaliser le projet à la date prévue. J'étais le seul à faire remarquer que nous avions des mois, pas des semaines, de travail à faire. Malgré mon avertissement, l'agence a décidé d'y aller. Ils ont raté. Non seulement le client s'est séparée de l'agence, mais on l'a laissé tomber sur un projet important », explique Jason Swett.
Éviter ce problème nécessite une combinaison de confiance et de perception des bonnes questions à poser. Jason Swett suggère d'utiliser les questions suivantes : les prévisions englobent-elles trop de projets à la fois ? Si une tâche est prévue pour une semaine ou plus, est-ce un signe que le travail doit être décomposé en tâches plus petites, dont chacune doit être déterminée séparément ? Sommes-nous trop optimistes ?

8. Se concentrer sur les mauvaises statistiques
Remplir un grand nombre de tâches est tout ce qui compte, non ? Si cet effort est appliqué aux mauvaises mesures, la productivité ne mène nulle part.
« En informatique, il est important de se demander comment mesurer la productivité », explique Félix Acosta. « Les solutions possibles comprennent l'expédition de nouveaux codes, la disponibilité de l'infrastructure, le nombre d'heures travaillées par votre personnel et par ticket. Le problème avec toutes ces métriques est qu'elles sont très mal alignées avec les revenus ou la rentabilité, donc il y a une manière de gérer l'informatique dans toute organisation et il faut la définir ».

Bruce Harpham / CIO US (adapté par Didier Barathon)