Pour une bonne gestion de projet, il est important de pouvoir se représenter les tâches, le temps, les coûts… mais jusqu’où faut-il aller ?

Je me souviens d’un âge d’or de la gestion de projet détaillée où il était de bon ton de prévoir l’imprévisible, où les chefs de projet passaient 4 heures par jour à corriger leur diagramme de GANTT sous Microsoft Project.

Pourquoi critiquer ce genre de méthode me direz-vous ? Ne fonctionnent-t-elles pas ? Bien entendu, elles ont fait leurs preuves et fonctionnent toujours, toutefois elles ont été créés pour une monde révolu. Pour revenir à lui, le diagramme de GANTT a été créé il y plus d’un siècle pour l’ère de l’industrie où tout était figé. Une machine qui coulait 25 pièces d’acier par heure n’en coulait pas 26, et quand on construisait une usine et achetait des machines, c’était pour faire tourner le tout durant 20 ans. Aujourd’hui le travail s’apparente plutôt à contacter des clients, ajouter des lignes de code, répondre à des emails… et vous ne ferez pas ce même travail durant 20 ans, le monde a changé.

Aucun plan ne survit au contact de l’ennemi
Sun Tzu

Avec le passage à l’ère des services, mais aussi au numérique, ce type de planification militaire n’est plus utile. Je ne dis pas qu’il ne fonctionne, mais qu’il consomme trop de temps, il y a donc un mauvais retour sur investissement.

Un simple exemple : quand vous êtes sur la route des vacances, vous arrêtez-vous au bord de la route pour savoir s’il vous reste 121 ou 122.5 km à parcourir ? Non, ce serait ridicule, mieux vaut rouler et savoir qu’il reste 120 à 130 km. Les informations les plus pertinentes seraient de se renseigner sur l’état de la route à suivre, s’il n’y a pas de perturbation, s’il existe une meilleure alternative. Malheureusement, en gestion de projet, beaucoup trop de personnes gaspillent des heures de travail pour mettre à jour une prévision de 121 à 122.5 !

Si dessiner la carte prend plus de temps que de construire la maison : vous avez un problème!

Sans mettre le doigt sur une méthode en particulier, voici quelques points qu’il faut éviter :

Corriger le plan passé

La seule chose qui doit être toujours correctement détaillée, c’est la comptabilité. Pour le reste, si vous vous surprenez à faire de la rétro-correction dans votre outil de planning, posez-vous cette question : « Que vais-je faire de cette information ? » Si personne ne sait répondre à cette question dans votre entreprise, probablement que vous nagez dans des informations inutiles.

Etre une esclave de la méthode

Bien trop de personnes suivent une méthode comme s’il s’agissait des 10 commandements.  La seule méthode à suivre est le bon sens. Pour en savoir plus, pensez à lire [#PROductivity5]

Planifier sur plusieurs années

A moins d’être liseur de bonne aventure, pas besoin de planifier votre projet dans le détail sur 5 ans. Non pas qu’il faille fermer les yeux sur l’avenir, mais si vous donnez la même précision à la semaine prochaine qu’à l’année prochaine, c’est soit que vous ne détaillez pas assez votre travail prochain, soit que vous détaillez trop votre travail lointain. Pensez à un tamis à plusieurs étages, dont chaque filtre est de plus en plus petit ; ce qui est loin de vous serait des gros cailloux et proche de vous du sable fin. Affiner au fur et à mesure n’est pas une fainéantise, mais le constat simple que beaucoup d’éléments planifiés à long terme disparaissent avant d’être réalisés ou en subissant un profond changement : ne détaillez pas trop l’imprévisible. 

Penser que tout se déroulera selon le plan

Le scénario n’est pas le film et la carte n’est pas le territoire, n’essayez de vouloir les faire correspondre à tout prix jusqu’à refuser le changement.

Garder l’état réel secret

Certains chefs de projet possèdent une sorte de honte si la réalité ne s’est pas déroulée selon le plan et préfèrent cacher l’état réel de la situation. A ce moment-là, le plan ne devient plus une représentation simplifiée ni une estimation d’une réalité possible, mais un mensonge.

Le nouveau vent qui souffle au loin les anciennes méthodes de projet « en cascade » qui s’attachaient à vouloir détailler et figer dans le béton la moindre minute de travail pour la prochaine année à venir, laisse place aux méthodologies Agiles (Lean, Scrum, Kanban…) qui préfèrent donner une estimation, une tendance.

Souvenez-vous : si vous passez plus de temps à planifier une tâche qu’à la réaliser… vous allez trop loin !

Les méthodes permettent de mettre des processus en place de manière rationnelle. Il est particulièrement pratique pour un débutant de suivre un manuel et de mettre en place tous les éléments comme indiqué, surtout quand on n’a pas encore une vision complète de son outil. Par contre, une fois la méthode maitrisée, il est important de s’approprier les outils et de les faire siens.

Que l’on parle de Lean, RUP, PMI PMP, Prince… l’avantage d’une méthode, même si on peut le critiquer, est de placer des normes et de permettre à tout le monde de parler le même langage. Toutefois, j’ai rencontré trop d’extrémistes de la méthode qui utilisaient un nombre de ressources non négligeable pour appliquer des processus qui ne leur étaient pas utiles au final, mais ils le faisaient : car cela était inscrit dans un livre.

Le chef de projet (qui en plus de la gestion de différents projets) mesure 90 KPI (Key Performance Indicator) ; il y passe des heures et en est fier. Mais quel en est le but ? Le but d’un KPI est de mesurer, de prendre la température d’une partie de votre entreprise et au final de prendre des mesures pour corriger, améliorer son fonctionnement. Peut-on véritablement suivre 90 indicateurs et corriger sur 90 points en même temps ? Je pense que c’est inefficient.

J’ai mené nombre de développements en utilisant la méthodologie SCRUM… Cette dernière possède des caractéristiques très simples et utiles : tel que réaliser des blocs de travail nommé sprint qui sont de 2 à 4 semaines et calculer la vélocité de chaque sprint (la masse de travail fourni). Cela est particulièrement utile si vous avez des comptes à rentrer auprès d’un client qui vous a passé la commande de ce travail (facturation en régie). Toutefois dans d’autres cas, comme la réalisation de notre propre produit en mode SaaS, il y avait certaines caractéristiques qui nous encombreraient, les voici :

• Premièrement, nous n’avions pas envie de nous limiter à des périodes préalablement fixées à un certain nombre de semaines. Ce qui semblait important pour nous n’était pas d’être fidèle à un calendrier, mais d’ « amener de la valeur dans notre produit ». Partir du postulat « J’ai 2 semaines à dispo : que vais-je mettre dedans ? », nous paraissait erroné, nous lui préférons : « Je veux que mes utilisateurs puissent payer à la réservation ; combien de temps cela va-t-il prendre ? ». Et nous créons une Milestone de durée nécessaire : 1, 2, 3 semaine(s) ; par contre, nous gardons les enseignements qui nous paraissent fondamentaux et utiles pour nous, nous n’allons pas commencer à développer sur plus d’un mois sans faire une release.

• Deuxièmement, tout l’effort investi pour mesurer les tâches, en vaudrait-il forcément la peine ? Non, pas pour nous. Je ne dis pas que c’est pas utile dans l’absolu, mais ce n’était pas utile dans ce cas précis.

Ce n’est pas votre entreprise qui doit s’adapter à la méthode, mais votre méthode qui doit s’y adapter pour vous fournir le meilleur retour sur investissement. Il n’y a que dans la phase d’apprentissage qu’il est utile de suive à la lettre les méthodes, une fois rendu dans le monde professionnel, il faut s’approprier les méthodes… ou en invente d’autres !

Ce billet a été écrit en partenariat avec :