Warning: Use of undefined constant simple_breadcrumb - assumed 'simple_breadcrumb' (this will throw an Error in a future version of PHP) in /homepages/18/d232980052/htdocs/wp-content/themes/one-page-theme/single.php on line 11

Regarder en arrière : mettre en place des rétrospectives et bilans de projet


Nous constatons tous régulièrement combien il est difficile, dans toute activité de projet, de faire de véritables bilans, post-mortem, ou rétrospectives. Quand le projet s'achève et que le moment est venu de le clore, le bilan produit, s'il en existe, est trop souvent minimaliste, voire une simple formalité. Et ce quelle que soit la méthodologie projet choisie. D'où vient cette réticence à prendre le temps de se poser, de regarder en arrière ? Aurions-nous peur d'être changé en statue de sel si nous le faisons ? Il peut être utile de s'interroger sur les raisons profondes qui nous empêchent de le faire.

Une utilité contestée

Le projet, cette activité gourmande en temps et en énergie, avait un but, qui a été réalisé. Si c'est fini, pourquoi y revenir ? Le bilan de projet ne va rien ajouter au logiciel, au pont, au processus, au terminal d'aéroport, qu'on vient de célébrer avec toute l'équipe. Rouvrir le dossier du projet fini est souvent perçu comme une exigence administrative à satisfaire, une requête du bureau des méthodes à laquelle il faut bien satisfaire si l'on veut conserver son label 5A ou autre certification. Certes, le bilan de projet produit de la connaissance, mais est-ce vraiment utile aux activités opérationnelles ? Ce qu'attend le management, c'est un produit fini; le bilan, c'est la cerise sur le gâteau. S'il est là, tant mieux, s'il est absent, on ne va pas en faire un drame !

La parade : la valeur ajoutée des bilans de projet ne se situe pas au niveau des produits livrés par le projet, mais de l'ensemble du processus. C'est avec le bilan de projet que l'on a véritablement le moyen de faire le point sur ce qui s'est passé, sous l'angle quantitatif (mise à jour d'abaques, stockage des données du projet pour développer une base statistique), mais surtout qualitatif : on déballe les problèmes, on explique les réussites, et on réfléchit sur les meilleures façons à l'avenir d'éviter les premières et de reproduire les secondes. La rétrospective ou bilan de projet est la séquence indispensable à la mise en place d'une véritable amélioration continue. C'est même la première à systématiser, et ce quelle que soit la méthode projet choisie (agile, cycle en V, ...).

Une disponibilité problématique

Dans le contexte des organisations qui ont mis en place une culture à projets, les individus sont souvent sollicités au-delà de leur capacité (il y a de multiples raisons à cela, mais ce sera le sujet d'un autre billet). Si on ne peut tout faire, il faut bien faire des choix et l'activité de bilan de projet, perçue comme apportant peu de valeur, en fait trop souvent les frais. Parfois, le choix n'est même pas offert, puisque les ressources du projet ont été allouées à d'autres sujets avant de pouvoir clore proprement leur précédent chantier.

La parade : il y a deux moyens d'éviter cela. Le premier est d'inclure dans la "Definition of Done" le bilan de projet, c'est-à-dire considérer que le produit fini est livré avec une documentation qui comprend le bilan de clôture. L'autre est d'augmenter les abaques sur lesquels se base l'estimation initiale de charges, pour l'activité de bilan de projet : cette activité est trop souvent sous-estimée, quand le budget qui lui est alloué n'est pas tout simplement récupéré par une qui a consommé l'intégralité du sien.

Une culture du futur

Dans nos sociétés préfiguratives, où la culture du futur et les figures de l'anticipation (prévision, prospective, planification) dominent, le projet accomplit, à titre individuel, deux fonctions : "il matérialise la pensée, ce qui donne l’occasion à l’auteur de mieux savoir ce qu’il veut ; il communique la pensée, ce qui permet à autrui de ne pas rester indifférent face à l’intention qui lui est présentée." Sous cet angle-là, le projet est donc fondamentalement anhistorique, et ne se soucie pas du passé. Dès lors, comment valoriser une activité qui consisterait à examiner les prévisions passées ? A l'échelle du projet, cela aurait autant d'intérêt que de faire l'exégèse de vieux livres de science-fiction comme ceux de Jules Verne ou H. G. Wells pour comprendre la société actuelle.

La parade : insister sur la temporalité du projet et l'équilibre des trois séquences : le futur ; le présent; le passé. A chacune de ces séquences correspond une activité, voir un document. Le projet est posé sur un tabouret à trois pieds. Si l'on en retire un, on dégringole.

Temporalité Activité Cycle en V Agile (Scrum)
Futur Planification Plan de projet Release Planning Meeting, Sprint Planning Meeting
Présent Suivi Reporting projet, diagramme de Gantt, ... Release Burndown Chart, Sprint Burndown Chart
Passé Bilan Bilan de projet, Post-mortem Sprint Retrospective

Un travers managérial

Le projet est proposé par l'organisation à partir de la vision managériale. Celle-ci s'appuie sur une pensée rationelle et utopiste, au sens propre : elle essaie de créer un modèle meilleur (la définition de "meilleur" pouvant fortement varier). Comme tout modèle utopique, le projet ne résiste pas à l'immersion dans la réalité, et en est fortement altéré. Il y a des amendements, des dérives, des compromis, et le résultat final est forcément différent de ce qui avait été planifié. Faire le bilan d'un projet, c'est forcément confronter la vision initiale avec la réalisation, et les biais cognitifs sur lesquels reposent la volonté planificatrice du management n'y survivraient pas. On préfère donc faire de la langue de bois, et, si un bilan de projet est vraiment requis, se focaliser sur un document plutôt neutre vite archivé, plutôt qu'une réunion où l'on expose vraiment les problématiques.

La parade : passer aux méthodes agiles. Si, dans votre organisation, cette raison est la dernière pour laquelle les bilans ne sont pas faits, c'est que le bilan de projet n'est pas la séquence où l'on vous autorisera à contester la légitimité d'une autorité bâtie sur la compétence prédictive. Donc plutôt que de vous opposer à cela, utilisez une méthodologie - ou a minima des éléments - qui ne demandent pas la validation du projet par la vision managériale. Mais même en utilisant Scrum, il vous faudra encore lutter pour organiser de véritables rétrospectives.

A lire aussi :

Source de l'image : Wikimedia Commons - sous licence Creative Commons - Share Alike

Contactez-nous

42 rue de Maubeuge
75009 Paris

Suivez-nous

Tous textes sous licence Creatice Commons CC-BY - Mentions légales Licence Creative Commons