Améliorer le reporting des projets IT avec le Lean management n’a rien d’habituel pour moi. Pourtant, après avoir rencontré le management de cette DSI, l’objectif est posé de la manière suivante : « faire le suivi de nos projets le plus efficace possible tout en dépensant le moins d’énergie. »
Pour caractériser davantage le problème, les chefs de projets passent en moyenne 5 heures par semaine et par projet à produire du reporting. Les informations nécessaires au suivi des projets sont diluées dans pas moins de 20 documents différents ! 20 documents plus ou moins complets qui sont produits avec une fréquence allant de la semaine au mois. Et pour ajouter encore à la confusion, certaines informations sont même contradictoires en fonction de leur fraicheur. Le management se retrouve ainsi à découvrir tardivement que certains projets sont en grande difficulté.

Qu’avons-nous fait ? Avec un groupe de 8 chefs de projet, nous nous sommes mis d’accord sur les informations et alertes essentielles pour le suivi des projets, regroupées en 5 items : le scope initial et les modifications éventuelles, le planning et les retards, la qualité, la disponibilité des personnes et la tenue du budget.
A la question « Que voulez-vous arrêter de produire ? », le groupe converge très vite vers la nécessité de réaliser un document unique pour chaque projet, mis à jour chaque semaine dans un répertoire partagé, accessible à tous. Pour chaque item, nous avons cherché à rendre les choses très visuelles : un graphique faisant apparaître en rouge ce qui ne va pas et au-dessous les explications du type Problème / Cause / Action / Résultat.
Un modèle est mis à disposition ainsi qu’un document pour expliquer son utilisation. Les 25 chefs de projets sont formés individuellement ainsi que leurs responsables. Dans les semaines qui suivent, avec l’utilisation de ce nouveau reporting, plusieurs améliorations sont apportées en fonction des difficultés remontées.

Quel en est le résultat ? 7 semaines après son lancement, 90 % des projets utilisent le nouveau reporting de manière hebdomadaire. Le temps consacré est passé de 5 heures à environ 1 heure par semaine. L’objectif numéro 2 de dépenser moins d’énergie est donc bien atteint.

Mais comment vérifier le premier objectif d’avoir un suivi plus efficace ? Par le gemba. J’ai d’abord assisté à une revue projet par le management : près de 40 projets en 2 heures, ça ne laisse pas de temps aux détails. Les reportings ont été construits dans ce sens avec un slide de synthèse en première page. Pour autant, seulement 2 reportings seront ouverts et 9 problèmes sur 21 seront entendus. En debrief avec la responsable, je comprends qu’elle connait déjà beaucoup de sujets par cœur, et qu’elle regarde les reportings en parallèle (d’ailleurs plusieurs chefs de projets ont reçu des remarques ou des questions de sa part). Nous ne nous sommes arrêtés que sur ceux qu’elle connaissait moins.
Ensuite j’ai accompagné plusieurs chefs de projets dans leurs comités de pilotage avec leurs clients métier et leur management. A chaque fois, que ce soit depuis la synthèse ou dans le détail des graphiques, la discussion s’engage autour des 2 ou 3 problèmes du projet et se termine avec des prises d’action ou des décisions. Voilà qui valide une première forme d’efficacité.

Toutefois, mon œil d’expert Lean me fait entrevoir d’autres perspectives : de l’aveu même des chefs de projet, ce reporting leur sert à communiquer : « Pour le comité de pilotage, ça m’a permis de rester focalisée sur les messages essentiels que je souhaitais passer. », « Les échanges sont plus rapides et plus clairs, d’ailleurs on a réduit de 1h à 30 minutes la durée du meeting avec le business chaque semaine. » … mais il ne leur sert pas à piloter le projet avec leur équipe.

Comment les challenger et les aider à livrer un produit de qualité en tenant les délais et le budget ? Comment leur permettre de capitaliser sur les problèmes rencontrés et d’en apprendre quelque chose ? C’est une autre histoire. Et ce sont d’autres PDCA.