Avant de partir pour le week-end, nous faisons une petite pause à la cuisine du bureau pour échanger entre collègues. C'est ainsi que nous concevons notre série d'articles « 5 questions à », dans laquelle nous interrogeons des chefs de projet expérimentés sur leurs meilleures pratiques.
Aujourd'hui, nous rencontrons Jan Fischbach. Il est directeur général du cabinet de conseil en organisation CommonSense, formateur pour les événements Scrum et co-organisateur du freiräume.camp dédié à une nouvelle culture du travail.
1. Monsieur Fischbach, quelle est votre méthode de gestion de projet préférée ?
Nos clients font appel à nous principalement pour deux raisons : des projets organisationnels (par ex. l'implémentation d'un logiciel ERP ou d'un système de gestion documentaire) ou l'introduction de structures de travail agiles (Scrum, etc.), ce qui constitue bien entendu aussi un projet organisationnel. Dans les deux domaines, nous utilisons principalement Scrum.
La communauté ne considère pas Scrum comme une méthode de gestion de projet, mais comme un processus d'équipe et un moyen de développer de bons produits. Et c'est précisément l'objet de nos projets : former des équipes qui commencent à livrer un produit et l'améliorent en continu. Pour nous, la gestion de projet signifie livrer des résultats dans l'incertitude. Les projets ne sont pas approuvés, ils sont financés. Avant de parler de planification des tâches et des délais, l'équipe doit bien comprendre collectivement quels résultats doivent réellement être livrés. À cette fin, nous nous appuyons sur la planification basée sur les produits de PRINCE2, la gestion de la valeur acquise (ANSI 748), la gestion des bénéfices (Ward/Daniel), le management de projet par la performance (Alleman), le User Story Mapping (Patton) ou l'Impact Mapping (Adzic).
Les dirigeants et les équipes sous-estiment souvent le niveau réel d'incertitude. C'est pourquoi nous utilisons le modèle en losange de Shenhar/Dvir pour expliquer l'incertitude dans les projets. Pour les projets importants, nous recommandons d'évaluer la probabilité des délais et des coûts à l'aide d'une simulation de Monte-Carlo. Celui qui travaille avec des estimations à trois points pour ses lots de travail les plus importants et examine 1 000 scénarios avec des nombres aléatoires constate souvent que ses premiers plans étaient très improbables.
Au passage, Ken Schwaber et Jeff Sutherland ont publié en novembre 2017 la nouvelle version du Guide Scrum.
2. Utilisez-vous des logiciels pour les projets d'envergure et, si oui, lesquels ?
Nous ne sommes pas de grands adeptes des logiciels. Ce n'est pas dû au logiciel lui-même, mais à la façon dont il est utilisé. Notre objectif est de constituer des équipes stables qui travaillent ensemble en un même lieu. Pour cela, un mur libre, des post-it et des paperboards suffisent souvent. Lorsque les membres de l'équipe sont répartis sur plusieurs sites, un support numérique peut s'avérer utile. Mais même dans ce cas, nous préférons photographier les tableaux et les enregistrer dans un espace de stockage partagé.
Nos clients utilisent fréquemment JIRA et Trello. Cependant, le volume de données dans ces outils augmente plus vite que les équipes ne peuvent le traiter. Les données sont saisies avec zèle, et la maintenance devient de plus en plus lourde à mesure que les champs obligatoires se multiplient. À un moment donné, personne ne sait plus ce qui a été livré ni quels travaux restent en attente. Le chargement des pages et les recherches prennent davantage de temps. Certains membres de l'équipe contournent le logiciel pour avancer dans leur travail. Dans ces situations, il est judicieux d'interrompre l'utilisation et de s'interroger : que voulions-nous réellement accomplir avec ce logiciel ? Bien entendu, de nombreux produits permettent aussi de gérer des points ouverts et de comptabiliser des heures. Mais est-ce vraiment la vocation de ce logiciel ?
3. Quel est votre rituel préféré dans un projet ?
J'utilise volontiers le Story Mapping. Nous rencontrons toujours d'excellents collaborateurs chez nos clients. Ce qui manque souvent, c'est une vision partagée des choses. Le Story Mapping est vraiment utile pour cela. Nous consacrons une à deux heures à mieux comprendre un processus ou la structure du produit, et à en déduire les priorités de travail. Nous nous appuyons ensuite sur ces cartes lors des événements de Refinement et de planification.
4. Quel est, selon vous, le facteur le plus sous-estimé pour la réussite d'un projet ?
a) Penser en termes de résultats : Lorsque j'examine différentes études sur la gestion de projet (par ex. celle de PwC : Insights and Trends: Current Portfolio, Programme, and Project Management Practices, The third global survey on management), je conclus que les projets n'échouent pas par manque de connaissances en gestion de projet. Je crois que trop souvent notre conception même du travail en mode projet nous freine. La gestion de projet va bien au-delà de l'élaboration et de la tenue de listes de tâches et de plans de coûts. Elle consiste à livrer des résultats dans l'incertitude. La question essentielle est toujours : que voulons-nous livrer ou transformer ? Dans les projets ERP, l'objectif n'est pas de mettre en place des systèmes techniques. Les utilisateurs ont besoin de fonctionnalités précises : imprimer des bons de livraison ou des factures. Dans les projets GED, il ne s'agit pas de stocker des documents, mais de clore des processus en équipe ; et pour cela, nous avons besoin de documents. Quelles compétences voulons-nous maîtriser ou avoir améliorées à l'issue du projet ?
b) Les projets sont financés, pas approuvés : Trop souvent, les projets sont considérés comme des générateurs de coûts. La communauté agile a fait évoluer son point de vue : dans cette perspective, on ne conduit pas des projets, on préfinance des produits qui permettront de gagner (ou d'économiser) de l'argent. Du point de vue agile, et d'ailleurs aussi selon PRINCE2, la rentabilité (valeur métier, cas d'affaire) est au premier plan. Après que nos clients ont estimé les coûts du projet, je leur demande souvent quelles pratiques de travail doivent concrètement changer pour que l'entreprise en gagne le double ou le triple. Ce sont des discussions très stimulantes. Dans un contexte véritablement agile, un Product Owner n'est pas un chef de projet, c'est un entrepreneur.
5. Quel est votre plus grand gaspilleur de temps ?
Les réunions sans objectif précis : J'apprécie Scrum parce que les cérémonies redeviennent des événements. Chaque événement Scrum a un objectif clair : on planifie quelque chose ou on examine les résultats. Il ne s'agit pas de ce qu'une personne a déjà accompli, seuls les résultats sont évalués. Cela libère de l'énergie. Dans les mauvais projets, des réunions de statut passent en revue des listes beaucoup trop longues. Des adultes redeviennent des écoliers qui expliquent à leur professeur pourquoi ils n'ont pas fait leurs devoirs. C'est désastreux. Au lieu de s'attaquer aux causes d'une planification irréaliste, on met les gens sous pression. Ce système ne fonctionne pas.
La surcharge : Chez tous nos clients, la liste des travaux en cours est trop longue. Ils s'engagent sur beaucoup trop de fronts en même temps. Le passage d'un chantier à l'autre consomme énormément de temps. Avec cinq projets simultanés, un collaborateur consacre les trois quarts de son temps à basculer entre les projets : il assiste à des réunions de statut, rédige et lit des comptes rendus, effectue des passations. Tout cela représente du travail qui n'apporte aucune valeur aux résultats, mais qui épuise considérablement.
Merci pour votre temps et bonne continuation pour votre prochain projet.
Si vous avez des questions sur cet article de blog ou si vous souhaitez en discuter, nous attendons avec impatience votre contribution dans notre forum.
