elles apportent souvent plus de problèmes qu’elles n’en résolvent
L’un des rôles du chef de projet est d’éliminer le plus rapidement possible tout obstacle qui empêcherait l’équipe projet de progresser. Nous sommes donc souvent en mode “résolution de problèmes”. Nous essayons de répondre aux problèmes qui surgissent, et d’éviter et/ou atténuer les risques connus.
Il est cependant utile de nous poser la question de savoir si ce que nous essayons de résoudre est réellement le problème ou bien seulement un symptôme du problème? En d’autres termes, notre réponse ou réparation rapide s’attaque-t-elle à la cause première/racine du problème ? Ou est-ce une étape dans la bonne direction pour réparer le problème de fond ?
Si la réponse à l’une de ces questions est positive, nous pouvons progresser avec cette réparation rapide (“quick fix”). Mais cela n’est pas toujours le cas …
Cet article est inspiré d’une session de formation que j’avais organisée et suivie pour le bureau de l’association PMI France-Sud. Jerry Brightman, un expert renommé du leadership et Président de la société The Leadership Group, fut l’animateur de cette session éducative.
Prenons un exemple pour illustrer le sujet et suivons le pas à pas pour mieux comprendre ce qui pourrait se produire : « un membre de l’équipe entre dans votre bureau pour annoncer un possible retard sur l’un de ses futurs livrables ». Un cas totalement improbable dans la vie réelle. ;-)
voici comment cela commence souvent :
2. Nous appliquons alors une réparation rapide. Ce livrable est sur notre chemin critique, nous proposons de lui octroyer un peu d’aide supplémentaire pour terminer dans les délais prévus.
Supposons que cela fonctionne et répare en effet le symptôme. Dans notre exemple, la tâche à réaliser est de nouveau dans les temps. Cependant, sommes-nous sûrs d’avoir :
a) attaqué la cause première/racine du problème et
b) évalué les effets secondaires potentiels de cette réparation rapide ?
voyons ce qui arrive trop souvent après une réparation rapide
3. La réparation rapide adresse le symptôme mais elle a quelques effets de bord secondaires. Par exemple, l’aide supplémentaire sur une tâche provoque un retard sur une autre tâche dont nous avons subtilisé des ressources. Ou encore, elle produit des demandes d’autres membres pour obtenir davantage de ressources, ou elle démotive un membre de l’équipe qui fournissait des efforts supplémentaires importants pour tenir les délais sur sa propre partie du projet, ou …
4. Ces effets de bord se manifesteront immanquablement par de nouveaux symptômes : baisse de moral dans l’équipe, menaces de retards sur d’autres parties du projet, absentéisme …
5. Nous serons tentés d’adresser ces nouveaux symptômes par davantage de réparations rapides. La boucle est bouclée ! La petite réparation rapide initiale pourrait bien avoir mis tout le projet à risque.
alors, que faire ?
La solution proposée est de s’efforcer par tous les moyens d’éviter d’entrer dans cette spirale infernale.
Dans l’étape 1, lorsque nous observons le symptôme (la menace d’un retard de livrable critique), prenons un peu de recul pour comprendre pourquoi le symptôme est là et quelle en est la cause racine. Nous devrions poser à l’équipe et à nous-mêmes certaines questions, ici :
- Les évaluations de charge étaient-elles incorrectes ?
- Un risque non anticipé s’est-il imposé à nous ?
- Un risque identifié a-t-il été incorrectement managé ?
- Un changement dans les besoins est-il en cause et comment a-t-il été géré ?
- Les ressources n’étaient-elles pas disponibles quand elles auraient dûes l’être ?
- La courbe d’apprentissage des nouveaux dans l’équipe a-t-elle été mal appréciée ?
- Avons-nous rencontré des difficultés techniques ?
- …
Nous voyons que les réponses à ces questions vont nous amener dans une 2ème étape à une réparation toute aussi rapide mais peut-être totalement différente et certainement plus adaptée à adresser la cause première/racine et éviter ou anticiper certains des effets secondaires.
Comme Seth Godin l’a dit fort justement dans l'un de ses articles "raser les ours polaires ne résoudra pas le réchauffement climatique", ou comme mon enseignant en premiers secours nous le répétait : “ne mettez pas de pansement sur une blessure qui n’est pas désinfectée, cela ne résoudra pas le problème et pourrait causer encore plus de dégâts !".
Michel
Crédit photo : © Secret Side - Fotolia.com
I've been leading IT projects for more than 20 years at telecom and computer manufacturers: Thomson Sintra, Digital Equipment, NCR, Nortel Networks, Orange Business. My passion is Project Management and leadership and I run a blog on the PM best practices at http://dantotsupm.com/