Nous avons tendance à porter une confiance excessive aux outils avec lesquels nous sommes familiers même en présence de bien meilleures options.
Ce biais est aussi connu sous le nom de la loi de l’instrument ou le marteau de Maslow. Comme l’avait dit Abraham Maslow en 1966, « J’imagine qu’il est tentant, si le seul outil dont vous disposiez est un marteau, de tout considérer comme un clou ».
En quoi suis-je concerné dans mes projets ?
Si le seul outil que connait votre nouveau manager de projet est Excel, il y a de très fortes chances pour que votre Gantt de projet soit réalisé en Excel. C’est déjà beau d’avoir un échéancier, mais il existe des outils plus flexibles en particulier pour gérer les dépendances, la charge des personnes affectées au projet, calculer le chemin critique…
De même, il peut être contre-productif dans votre projet Agile de vouloir faire de tous les besoins des User Stories.
Comment éviter le plus possible ce travers ?
Avant de commencer une tâche importante que vous n’avez jamais réalisée, cherchez à savoir ce qu’utilisent les professionnels du domaine et pourquoi. Le temps d’apprentissage de tout nouvel outil ou technique est souvent surestimé et ses bénéfices sous-estimés. Ne tombez pas dans ce piège.
Ce biais peut-il vous être utile ?
Il arrive que des outils que vous connaissez déjà puissent remplir la mission. Votre expérience peut vous permettre de valoriser le nouvel outil qui vous est proposé à sa juste valeur puis de prendre la décision réfléchie de changer d’outil ou pas.
Un exemple : Lorsque votre projet Agile est déjà bien avancé et que toutes vos User Stories sont documentées dans un outil, même imparfait, il peut être contre-productif de vouloir basculer vers un nouvel outil même plus performant à cause de la nécessaire reprise des données existantes.
Une variante corrélée à ce biais est la fixité fonctionnelle
Nous avons tendance à utiliser les outils et méthodes de la façon traditionnelle dont nous les avons toujours utilisés. Cette tradition d’utilisation existante peut limiter votre capacité à voir toutes les autres choses que ceux-ci sauraient faire.
Par exemple: La matrice des responsabilités des personnes sur le projet peut être adaptée pour produire une matrice de responsabilité des livrables du projet.
DantotsuPM.com 
Bien le bonjour à vous monsieur. Et merci pour ces multiples connaissances que vous partagez avec nous.
Ma préoccupation est la suivante: si passer a une gestion agile de projet engagerait du temps et des coûts supplémentaires, quel serait l’intérêt de ne pas rester à une gestion traditionnelle ?
J’aimeJ’aime
Bonjour, tout d’abord, je ne pense pas que le management de projet en approche Agile soit plus cher ni moins cher qu’avec les approches prédictives « en cascade » ou en V. Tout dépend en premier lieu de la capacité à définir très précisément tout ce que l’on a besoin de réaliser avec le projet pour qu’il délivre ses bénéfices. Si toutes les exigences sont claires et déjà priorisées, une approche prédictive est tout à fait adéquate et pas forcément moins chère car on va devoir tout développer, tout tester, tout déployer, et attendre que tout ceci soit fait pour en tirer les premiers bénéfices. Si les exigences ne sont pas si claires ou si une fraction de celles-ci pourrait déjà délivrer une valeur considérable au business, adopter une approche Agile me semble préférable. On travaillera sur un petit périmètre fonctionnel en proximité avec les utilisateurs et les développeurs pour une solution certes limitées mais qui réponde aux attentes et apporte plus rapidement de la valeur. Puis, on itèrera sur les fonctionnalités prioritaires suivantes et on s’arrêtera dès que le prochain incrément n’apporterait plus de bénéfices majeurs. Donc, on ne fera pas nécessairement tout ce qui était au départ envisageable. Pas forcément moins cher ni plus rapide mais on colle mieux aux attentes et on perçoit des retours sur investissement plus tôt. Michel.
J’aimeAimé par 1 personne