La délégation est l’une des compétences les plus citées dans les référentiels de gestion de projet, et l’une des moins bien pratiquées. La raison tient moins à un manque de volonté qu’à un malentendu fondamental sur ce qu’implique réellement le fait de déléguer.
Derek Sivers, dans un texte tiré de son livre “Anything You Want”, illustre le problème: quand un manager ajoute ses “deux centimes” au travail d’un collaborateur, il ne l’améliore pas nécessairement. Il transfère la propriété du résultat de l’employé vers lui-même. Le collaborateur, qui avait investi toute son énergie dans le projet, constate que son travail n’est pas considéré comme suffisant tel quel. Sa motivation chute et, avec elle, son engagement futur.
Déléguer ou distribuer des tâches?
La confusion entre délégation et distribution de tâches est à l’origine de nombreux dysfonctionnements en gestion de projet. Distribuer des tâches, c’est dire “fais ceci, de cette manière, et montre-moi le résultat pour que je le valide”. Déléguer, c’est dire “voici l’objectif, voici les contraintes, voici les ressources disponibles: propose-moi une solution”.
La différence est considérable. Dans le premier cas, le collaborateur est un exécutant dont le jugement n’est pas sollicité. Dans le second, il est un contributeur dont l’expertise et la créativité sont mobilisées. Le PMI (Project Management Institute), dans son Talent Triangle, place explicitement la capacité à responsabiliser les équipes parmi les compétences de leadership attendues d’un chef de projet.
En pratique, beaucoup de chefs de projet oscillent entre les deux modes sans en avoir conscience. Ils formulent la délégation comme une vraie délégation (“je te confie la rédaction du plan de test”) mais la traitent ensuite comme une distribution de tâches en réécrivant le plan paragraphe par paragraphe lors de la revue.
Le coût de l’intervention systématique
Sivers quantifie intuitivement le problème: un collaborateur qui présente un travail dont il est fier et qui reçoit une série de corrections mineures voit sa motivation chuter à 50%. Daniel Pink, dans “Drive”, démontre que l’autonomie est un des trois moteurs fondamentaux de la motivation intrinsèque, aux côtés de la maîtrise et du sens.
Dans un projet, les conséquences sont tangibles. Une équipe dont le travail est systématiquement retouché par le chef de projet développe un réflexe d’attente: pourquoi investir dans la qualité d’un livrable qui sera de toute façon modifié? Ce réflexe, une fois installé, est très difficile à inverser. L’équipe produit des ébauches en attendant les “vraies” directives du chef de projet, ce qui crée un goulet d’étranglement et ralentit l’ensemble du projet.
Construire le cadre avant de lâcher prise
La retenue managériale ne peut pas fonctionner dans le vide. Pour que le chef de projet puisse ne pas intervenir sur un livrable, il doit avoir investi en amont dans la clarification des attentes.
Cela suppose des critères d’acceptation explicites, définis avant le début du travail. Un template de livrable, quand il est pertinent, élimine les discussions de forme pour centrer la revue sur le fond. Des standards de qualité partagés et compris permettent à chaque membre de l’équipe d’évaluer son propre travail avant de le soumettre.
Le WBS (Work Breakdown Structure), la décomposition structurée du travail en lots et livrables, joue ici un rôle souvent sous-estimé. Un WBS bien construit définit ce qui doit être produit, le niveau de détail attendu et les critères de qualité pour chaque lot. Il devient un contrat implicite entre le chef de projet et l’équipe: tant que le livrable répond aux critères définis, il est accepté sans retouche cosmétique.
La règle des 90%
Sivers propose un seuil pragmatique: si le résultat est à 90% de ce que vous auriez fait, acceptez-le tel quel. Les 10% restants représentent le style personnel du collaborateur, ses choix d’approche, sa manière de résoudre un problème. Corriger ces 10% revient à imposer votre manière de faire au détriment de la sienne, sans bénéfice significatif pour le projet.
Cette règle est particulièrement applicable en gestion de projet multi-sectorielle. Un chef de projet qui pilote une équipe de spécialistes (ingénieurs, juristes, analystes métier) n’a généralement pas l’expertise pour juger si le livrable technique d’un spécialiste est optimal dans ses moindres détails. Son rôle est de vérifier que le livrable remplit sa fonction dans le contexte du projet, pas de le peaufiner selon ses propres critères.
Les limites de la non-intervention
La retenue ne signifie pas l’absence de suivi. Un chef de projet qui n’intervient jamais n’est pas un bon délégateur: c’est un chef de projet absent. La différence tient dans la qualité du cadre posé en amont et dans la capacité à intervenir de manière ciblée quand la situation l’exige réellement.
Les revues de livrables restent nécessaires, mais leur objectif change. Au lieu de chercher ce qui pourrait être “mieux”, le chef de projet vérifie que le livrable répond aux critères définis et s’intègre dans l’ensemble du projet. Les corrections portent sur la conformité et la cohérence, pas sur les préférences personnelles.