Le micromanagement ou l'art de démoraliser son équipe
La démarche à suivre pour faire échouer son projet selon Andrew Stellman

Le , par Victor Vincent, Chroniqueur Actualités
Auteur de plusieurs ouvrages ayant un franc succès dans le domaine de la gestion de projets et de la gestion d’équipes dont « Beautiful Teams » et « Head First PMP », Andrew Stellman a longtemps travaillé sur les causes qui mènent les projets informatiques à l’échec. Ce qui lui a valu ce qu’il appelle lui-même le titre d’expert dans les échecs de projets. Dans un travail récent, mené auprès de plusieurs entreprises, Andrew a essayé de dégager les principales causes des échecs de projets en se basant sur les retours des entreprises qui ont participé à l’étude ainsi que sur son expérience personnelle, mais aussi en analysant les pires échecs de grands projets tels que le pont du détroit de Tacoma.

Andrew Stellman soutient que la meilleure façon pour faire échouer son projet est de recourir au micromanagement. Il est facile pour un patron de tomber dans le piège du micromanagement selon lui, surtout précise-t-il quand le patron sent que le projet est en train d’échapper à son contrôle. Cela s’explique par le fait que quand le patron voit que le projet échappe à tout contrôle, il essayera par tous les moyens qu’il pourra trouver de pousser chaque employé de l’entreprise à faire l’impossible pour sauver le projet. D’après Stellman, la majorité des membres des équipes ont du mal à se rendre compte de cet aspect des choses, car la plupart du temps, ils ont l’habitude de travailler dans des conditions de pression extrêmes.

Par ailleurs, Andrew estime que : « si vous êtes un patron et cherchez un moyen de démoraliser votre équipe dans le but de faire échouer vos projets, le micromanagement est un bon moyen de le faire ». Il va même plus loin, en effet l’expert en échecs de projets a établi la marche à suivre pour se faire haïr par son équipe et mener son projet vers un échec total. Pour ce faire, il faut suivre une ou plusieurs des recommandations suivantes :
  • s’assurer de ne pas donner suffisamment de temps aux membres de son équipe pour exécuter un travail donné et leur reprocher ensuite d’être responsables du retard éventuel qui pourrait se produire ;
  • demander fréquemment aux gens d’arrêter immédiatement ce qu’ils font pour faire des tâches urgentes nouvellement identifiées et s’attendre à ce que ces dernières soient toujours exécutées sur-le-champ ;
  • ne jamais permettre à quelque membre de l’équipe qu’il soit de faire une livraison ou même de s’adresser aux utilisateurs sans votre aval ;
  • quand votre équipe fait une livraison, renvoyez-la-leur avec les changements que vous aurez décidé d’y apporter sans pour autant faire une estimation sérieuse du temps qu’il leur faudra pour les faire ;
  • trouver toujours de petits changements dans les livrables pour juste pour pouvoir occuper son équipe avant de leur trouver un nouveau projet ;
  • puisqu’une équipe a besoin d’être concentrée en permanence, si vous avez un membre de votre équipe qui n’a pas grand-chose à faire depuis deux heures, demandez-lui de faire une mise à jour d’une fonctionnalité déjà livrée ;
  • tenir des réunions de deux heures minimum chaque semaine pour que chaque membre de l’équipe fasse état de ses avancements, pour être sûr que tout le monde a fait ce que vous avez demandé de faire ;
  • si quelqu’un fait une chose différemment de la façon dont vous vouliez qu’il la fasse, réprimandez-le, quel que soit le résultat de son travail et dites-vous que chaque membre de l’équipe doit être en mesure de lire un peu dans vos pensées, ils ne doivent tout le temps s’attendre à ce que vous leur disiez ce qu’il y a à faire.

La clé du succès pour faire échouer un projet est très simple, poursuit Andrew. La règle à avoir en tête pour cela est que personne dans votre équipe n’a droit à l’erreur, parce que si un développeur fait une erreur cela va se répercuter sur le travail de l’ensemble de l’équipe. En outre, il ne faut jamais accepter d’avoir tort devant son équipe, sur quelque sujet que ce soit, pour ne pas passer pour un faible et si vous décidez que la nouvelle mode dans l’entreprise c’est de travailler dans le noir, personne n’a le droit de vous mettre en doute. C’est cela que l’auteur appelle le micromanagement.

Source : stellman-green.com

Et vous ?

Qu'en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de RyzenOC RyzenOC - Membre émérite https://www.developpez.com
le 23/12/2015 à 9:17
tenir des réunions de deux heures minimum chaque semaine pour que chaque membre de l’équipe fasse état de ses avancements, pour être sûr que tout le monde a fait ce que vous avez demandé de faire ;
En effet,

Pour qu'un projet réussisse il faut je pense faire 1 petite réunion chaque matin (de 15min max) afin d'identifier les difficultés et prévoir les futurs problèmes/retard pour trouver une solution.
Et si possible 1 réunion toute les 2 semaines avec le client.
Avatar de Orgoff Orgoff - Membre averti https://www.developpez.com
le 23/12/2015 à 9:24
Citation Envoyé par sazearte Voir le message
Pour ce point, sa dépend je dirais.

Pour qu'un projet réussisse il faut je pense faire 1 petite réunion chaque matin (de 15min max) afin d'identifier les difficultés et prévoir les futurs problèmes/retard pour trouver une solution.
Et si possible 1 réunion toute les 2 semaines avec le client.
Oui c'est effectivement une bonne pratique, ce qui est plus mis en cause dans l'article est l'intérêt et la durée de cette réunion (qui est 2x trop importante).
Avatar de xelab xelab - Membre éprouvé https://www.developpez.com
le 23/12/2015 à 9:47
Citation Envoyé par Orgoff Voir le message
Oui c'est effectivement une bonne pratique, ce qui est plus mis en cause dans l'article est l'intérêt et la durée de cette réunion (qui est 2x trop importante).
L'article original va bien plus loin:

All organizations run on status. If the status updates stop flowing, a company can crumble and perish! Also, developers feel lonely if they haven’t given a status update in the last few hours. So make sure everyone has to fill out elaborate status reports, and make sure you hold at least three two-hour-long status meetings every week.
En gros, c'est trois réunions de 2 heures par semaine et une incitation à remplir sans cesse des rapports d'activité...
Avatar de sebbod sebbod - Membre habitué https://www.developpez.com
le 23/12/2015 à 9:54
Et oui faire une réunion de 10/15 min par jour debout c'est très différent de 1 réunion de plus de 2H par semaine assis.
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 23/12/2015 à 17:45
Citation Envoyé par Victor Vincent Voir le message
s’assurer de ne pas donner suffisamment de temps aux membres de son équipe pour exécuter un travail donné et leur reprocher ensuite d’être responsables du retard éventuel qui pourrait se produire
ça en générale c'est le commercial qui te fille les modifs la veille de la livraison

Citation Envoyé par Victor Vincent Voir le message
En outre, il ne faut jamais accepter d’avoir tort devant son équipe, sur quelque sujet que ce soit, pour ne pas passer pour un faible et si vous décidez que la nouvelle mode dans l’entreprise c’est de travailler dans le noir, personne n’a le droit de vous mettre en doute. C’est cela que l’auteur appelle le micromanagement.
ça me rappel un point avec lequel je suis en désaccord avec mon supérieurs pour des raisons techniques et légales
mais j'ai tellement souvent raison que je fait les deux solutions et au final à 90% du temps c'est celle que je soutenait qui est validée
Avatar de - https://www.developpez.com
le 28/12/2015 à 0:34
Andrew Stellman soutient que la meilleure façon pour faire échouer son projet est de recourir au micromanagement.
Le macromanagement est pas mal dans le genre également...

Steph
Avatar de ZenZiTone ZenZiTone - Membre émérite https://www.developpez.com
le 28/12/2015 à 11:36
Citation Envoyé par Victor Vincent Voir le message
Et vous ?

Qu'en pensez-vous ?
Que le Management doit s'adapter au projet et à son équipe. C'est d'ailleurs là tout l'intérêt du management : emmener une équipe à réaliser un projet. Essayer de généraliser le management est, a mon avis, une erreur.
Avatar de Glutinus Glutinus - Expert éminent sénior https://www.developpez.com
le 28/12/2015 à 11:56
Citation Envoyé par Victor Vincent Voir le message
Qu'en pensez-vous ?
Que monsieur a raison et que s'il gagne sa vie juste en identifiant ce qui ne va pas sans apporter de solution, je veux bien faire de même
Avatar de Glutinus Glutinus - Expert éminent sénior https://www.developpez.com
le 28/12/2015 à 12:04
Citation Envoyé par sazearte Voir le message
En effet,

Pour qu'un projet réussisse il faut je pense faire 1 petite réunion chaque matin (de 15min max) afin d'identifier les difficultés et prévoir les futurs problèmes/retard pour trouver une solution.
Et si possible 1 réunion toute les 2 semaines avec le client.
Ouip, déjà vu.
"On fait un stand-up, promis aujourd'hui c'est 15 minutes".
Finalement ça dure une heure tous les matins car on tourne autour du pot...

Citation Envoyé par Orgoff Voir le message
Oui c'est effectivement une bonne pratique, ce qui est plus mis en cause dans l'article est l'intérêt et la durée de cette réunion (qui est 2x trop importante).
Le problème est pas tant la durée de la réunion. On peut très bien faire de bonnes réunions de deux heures assis, mais il faut que tout le monde soit impliqué. Double sens : il n'y a pas d'acteurs qui travaille en-dehors de ce qu'on parle, et que tous les acteurs interviennent, ou du moins soient très réceptifs à ce qu'on dit.
Et que la réunion soit bien maîtrisée en terme d'horaires et de gestion : si l'animateur voit qu'un point prend trop de temps, soit il prévoit un autre point uniquement avec les acteurs concernés (tous s'ils le sont tous), soit il résume et abrège rapidement.

Ce qui est amusant, c'est que les bouquins sur une bonne tenue de réunion c'est comme un bouquin sur les régimes : y en a 3.000, mais personne ne respecte ce qui est dit dedans.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 28/12/2015 à 15:40
Tiens, on dirait ma femme.....

(rien de misogyne là-dedans, je suis sur que plein de dames peuvent dire la même chose de leur mari )
Offres d'emploi IT
Ingénieur analyste programmeur (H/F)
Safran - Auvergne - Montluçon (03100)
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Data scientist senior H/F
Safran - Ile de France - Magny-les-Hameaux (Saclay)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil