La délégation est une compétence de chef de projet au même titre que la planification ou la gestion des risques. Pourtant, elle est rarement enseignée comme telle. On apprend à construire un planning, à estimer un budget, à identifier des risques. Mais la capacité à confier du travail à d’autres, à définir le bon niveau d’autonomie et à construire la confiance nécessaire pour que cette autonomie fonctionne s’acquiert le plus souvent par essais et erreurs. Les erreurs, en l’occurrence, prennent souvent la forme du micromanagement.
Pourquoi la délégation ne va pas de soi
Un chef de projet qui débute porte souvent la responsabilité de livrables qu’il produisait lui-même dans son poste précédent. La transition du “faire” au “faire faire” est un changement de posture fondamental. La tentation est forte de rester dans l’opérationnel: revoir chaque document, valider chaque décision, corriger chaque travail avant qu’il ne parte. Ce réflexe est compréhensible, mais il est aussi contre-productif.
Le problème n’est pas la volonté de bien faire. C’est l’absence d’un cadre structuré pour déléguer. Sans méthode, le chef de projet oscille entre deux extrêmes: tout contrôler (et étouffer l’équipe) ou tout lâcher (et découvrir les problèmes trop tard). Les outils de la gestion de projet offrent une troisième voie, qui consiste à déléguer de manière graduée et outillée.
Les niveaux de délégation: un spectre, pas un interrupteur
Jurgen Appelo, dans son ouvrage Management 3.0, propose un modèle de sept niveaux de délégation qui va de “dire” (le manager décide seul et informe) à “déléguer” (le collaborateur décide en totale autonomie). Entre les deux: “consulter” (demander un avis avant de décider), “s’entendre” (décision conjointe), ou “conseiller” (le collaborateur décide après avoir écouté l’avis du manager).
Ce modèle est utile parce qu’il montre que la délégation n’est pas binaire. Pour un même collaborateur, le niveau approprié varie selon la tâche, le risque associé et l’expérience de la personne dans le domaine concerné. C’est ici que le modèle de leadership situationnel de Hersey et Blanchard rejoint la question: un collaborateur compétent et motivé n’a besoin que d’un soutien léger, tandis qu’un collaborateur en apprentissage a besoin d’un cadre plus structurant. L’erreur du micromanager est d’appliquer le niveau de direction maximal à tout le monde, indépendamment de la situation.
Prenons un exemple concret. Dans un projet de déménagement de bureaux, le responsable logistique peut recevoir une autonomie de niveau 6 sur le choix des prestataires de son domaine: il décide et vous informe. En revanche, la communication aux collaborateurs sur le calendrier du déménagement reste à un niveau 3, parce qu’elle engage l’image de la direction et nécessite une validation avant diffusion.
L’exercice concret consiste à lister vos principales décisions et tâches du projet, puis à définir pour chacune le niveau de délégation approprié, en concertation avec les personnes concernées. Ce travail de clarification préalable évite les malentendus et les reprises: chacun sait ce qu’il peut décider seul, ce qui nécessite une consultation, et ce qui requiert une validation.
Le RACI: formaliser qui fait quoi, jusqu’où
Le RACI (Responsible, Accountable, Consulted, Informed) est un outil complémentaire qui clarifie les rôles pour chaque livrable ou décision du projet. Le Responsible exécute le travail. L’Accountable porte la responsabilité finale du résultat, il n’y en a qu’un seul par livrable. Les Consulted donnent un avis avant l’exécution. Les Informed sont tenus au courant du résultat.
Un RACI bien construit rend le micromanagement inutile parce qu’il répond d’avance aux questions qui, sans lui, poussent le chef de projet à intervenir: qui valide ce livrable, qui doit être consulté avant cette décision, qui peut agir sans validation supplémentaire.
En pratique, les problèmes de délégation se concentrent souvent au niveau du “A”: le chef de projet qui inscrit son nom dans la colonne Accountable de chaque ligne a formellement pris sur lui la responsabilité de tout. C’est une signature de micromanagement. Dans un projet bien structuré, la responsabilité finale est distribuée: le responsable technique est Accountable sur les livrables techniques, le responsable qualité sur les livrables de test. Le chef de projet reste Accountable sur la coordination d’ensemble et les livrables de pilotage.
Construire la confiance par le cadre, pas par le contrôle
La confiance ne se décrète pas. Elle se construit, et les outils de gestion de projet y contribuent directement. Quand les livrables sont clairement définis (via une WBS, ou Work Breakdown Structure, avec son dictionnaire), quand les rôles sont explicites (via le RACI), quand les seuils de tolérance sont convenus (comme le formalise PRINCE2 dans son principe de management by exception, la gestion par exception), vous disposez d’un filet de sécurité objectif. Vous n’avez plus besoin de surveiller le processus en permanence. Vous vérifiez les résultats aux jalons prévus.
Ce cadre profite aussi à l’équipe. Un collaborateur qui connaît précisément son périmètre de décision, ses critères de réussite et les limites au-delà desquelles il doit alerter travaille avec plus d’assurance qu’un collaborateur qui navigue dans l’implicite et risque à chaque instant de voir son initiative désavouée.
Que faire quand la délégation échoue?
La délégation échoue parfois. Un livrable ne correspond pas aux attentes. Un délai est dépassé. La réaction instinctive est de reprendre le contrôle: valider davantage, vérifier plus souvent, réduire l’autonomie. C’est précisément la réaction qui mène au micromanagement.
L’alternative est d’analyser l’échec. Le livrable était-il bien défini? Vos critères d’acceptation étaient-ils explicites et partagés? Le collaborateur disposait-il des compétences et des ressources nécessaires? Le niveau de délégation était-il adapté à sa maturité sur cette tâche? Dans la majorité des cas, l’échec de la délégation n’est pas un échec de la personne, mais un échec du cadre.
Renforcer le cadre (préciser les livrables, ajuster le niveau de délégation, augmenter la fréquence des points de synchronisation sans retomber dans le contrôle permanent) est une réponse proportionnée. Reprendre tout le contrôle est une réponse qui, en privant l’équipe de l’occasion d’apprendre, garantit que le problème se reproduira.