Par Emmanuel LE GOUGUEC, Directeur Industrie
Monsieur D. se rappellera longtemps la dernière réunion de développement, car celle-ci avait été catastrophique.
Le chef de projet se démenait comme un diable pour mobiliser ses ressources. Pourtant, chaque comité de pilotage débouchait sur davantage de retards. Ceux-ci prenaient chaque jour de plus en plus d’ampleurs et les problèmes finissaient par s’accumuler. Comment en était-on arrivé là ? Et si le problème était structurel et non conjoncturel. Alors seul un changement du système permettrait d’améliorer la situation. La perception de monsieur D. était que la gestion de projet se transformait peu à peu en un véritable cercle vicieux.
La société ne gérait pas qu’un seul projet : c’était quinze nouvelles initiatives, une dizaine d’actions internes et des demandes urgentes venant de clients plus exigeants qu’il fallait piloter, des priorités à modifier sans avoir de sentiment définitif sur leur impact. Le pilotage de ces activités de développement ressemblait à une boîte noire, à un système où chaque retard provoquait à son tour de nouveaux problèmes.
Monsieur D. réunit l’ensemble de ses chefs de projets et de ses responsables de service pour comprendre ce qui n’allait pas. La litanie des problèmes semblait sans fin. On en était contraint à :
Coordonner les activités de départements et d’entreprises variées,
Gérer plusieurs types d’activités avec des niveaux stratégiques et d’urgence différents (développement de projet nouveau, réponse commerciale, urgence qualité ou production),
S’appuyer sur plusieurs expertises désynchronisées ayant chacune ses contraintes et ses plannings propres,
Faire face à des délais incompressibles (ex. : certification …) ou difficilement gérables,
Naviguer en fonction de l’urgence et du coup de téléphone du moment, sans avoir une vision globale sur l’avancement des projets
Ne pas avoir de « chef d’orchestre » capable de donner le rythme global au processus,
Augmenter le nombre de projets à gérer en espérant que cela permettrait d’en sortir plus.
Malgré toutes les actions mises en œuvre (davantage de ressources et de temps pour les tâches et donc des délais de projets plus longs), le résultat global ne s’améliorait pas. On sacrifiait les quinze projets pour parer à la dernière urgence et les mêmes ressources étaient toujours débordées - alors que celles-ci ne faisaient même pas partie du département du développement. Quelque chose n’allait donc pas…
La gestion de projet moderne a été formalisée dans les années 30, à une période où les experts tayloristes pilotaient la production dans les usines, avec pour résultat des modèles PERT ou Gantt directement calqués sur les systèmes de production. On reprenait le principe de la gamme et de la nomenclature : une opération élémentaire, avec un temps standard, une responsabilité et une mesure.
On s’appuyait sur un mode de gestion où le suivi de chaque tâche assurait le pilotage global du projet. Les responsabilités s’organisaient sur des découpages par métiers, chaque atelier (ou service) pilotant sa charge et étant mesuré à partir de ce seul et unique indicateur.
L’ensemble du site était géré et piloté de la même manière, en appliquant le vieux principe selon laquelle des équipes qui ne font rien, c’est de la capacité de perdue – et ça, le comptable et le contrôleur financier n’aimaient pas du tout.
Pour comprendre ces problèmes, monsieur D. décida de lire un autre livre d’E. Goldratt, après avoir beaucoup aimé « Le But ». Il se plongea dans la lecture de Critical Chain.
Une fois de plus, ce fut l’illumination : que Goldratt écrivait bien ! On était loin des grands livres de théorie, mais on suivait l’intrigue, on vivait les problèmes, on découvrait les solutions. Par contre, la mise en pratique se révélait des plus complexes…
Voici ce que monsieur D. retint de ses lectures :
La durée totale d’un projet est la durée de la chaîne critique. Selon les règles de l’art, cette chaîne ressemblait fortement à un chemin critique où l’on aurait intégré la notion de ressource et de sa capacité.
Seules les tâches sur cette chaîne critique contribuent à la durée du projet. En fonction de la complexité du réseau, moins de la moitié des tâches sont sur ce chemin critique.
Donc, être en retard sur 50 % des tâches n’est pas forcément important, il faut surtout savoir sur quoi se concentrer.
Pour un projet, les durées données pour une tâche sont souvent plus importantes que les durées objectives nécessaires à leur réalisation. Il faut en effet y intégrer de nombreux éléments complémentaires : attente d’information, disponibilité à l’instant donnée ou phénomène de file d’attente.
Monsieur D. comprit alors un curieux phénomène qu’il avait constaté à plusieurs reprises:
Lorsqu’il demandait à un jeune ingénieur fraîchement sorti de l’école combien de temps il lui fallait pour réaliser un plan ou une modification, la réponse était de l’ordre de quelques jours. La même question posée à un vieux grognard (responsable développement compris) les quelques jours se transformaient invariablement en 2 semaines. Alors que le jeune ingénieur se trompait une fois sur 2, l’ingénieur expérimenté était d’une fiabilité digne d’une montre suisse. Sa réaction personnelle était toujours la même : pestant contre le manque de fiabilité du jeune, le délai du nouvel embauché devenait en moins de 3 mois le standard à 2 semaines.
Monsieur D. préférait la fiabilité de la prévision à la performance de la mise à disposition.
Un soir, il s’en ouvrit à son responsable R&D avec lequel il avait partagé tant d’histoires. Un brin goguenard, celui-ci lui donna sa vision :
- Lorsque je dois construire un planning – et un budget par la même occasion –, tu me demandes de m’engager sur des chiffres alors que je sais que les données commerciales ne sont pas respectées, que les spécifications techniques sont à construire et que tout reste à faire. De plus, avec le nouveau système de gestion, je sais qu’on suivra chacun des temps de mes gars et qu’on me demandera des comptes si les chiffres ne tombent pas ronds.
- Et alors ? - lui répondit monsieur D. - la précision des données est la clé d’une gestion saine : prévoir, suivre et décider sont les règles d’or du manager moderne.
- Bien sûr, bien sûr. D’ailleurs, tu remarqueras qu’on est globalement toujours dans les 2 % alloués - même si les fins d’années sont soit des opens-bars, où je m’empresse de dépenser ce qui reste, soit des serrages de vis complets. Avec l’expérience, en jouant sur les avancements de projets, on s’arrange pour tomber juste. Malgré les fortes différences locales entre projets, on se récupère globalement sur le portefeuille. Ce qui vous intéresse au COMEX, ce n’est pas de savoir si on est bon, c’est de suivre l’écart avec ce qui a été présenté en octobre dernier. Alors on se débrouille.
- Tu t’en tires parce que tu utilises la sécurité des autres projets ? Intéressant. Dans le livre dont je te parle, l’auteur parle d’une notion de Buffering. On réduit drastiquement la durée des tâches élémentaires en prenant par exemple les valeurs de nos jeunes ingénieurs : celles qui sont bonnes une fois sur deux. Cependant, on définit un buffer projet, qui correspond à la sécurité du projet. Ce buffer correspond à une durée représentant près de 50 % de la durée de la chaîne critique et intègre quelques éléments complémentaires. Par contre, on ne contrôle plus le délai donné par les opérationnels, car on considère qu’ils sont réalistes. En cas de problème, c’est le buffer projet qui les absorbe. Ainsi, le buffer constitue une assurance globale sur le projet.
- Pourquoi pas ? Mais il te faut une solution pour suivre l’avancement et calculer ces « buffer », car nos projets sont complexes et toujours très dynamiques.
Sur ces paroles, monsieur D. finit son whisky PC 8 en se disant que Jim McEwan avait eu une riche idée de relancer cette marque et que la tradition avait également du bon.
Une autre chose l’avait fortement surpris dans ce livre : c’était le point de vue de l’auteur sur la gestion du multitâche.
Selon Goldratt, le principe même de multitâche est à proscrire au maximum. En effet, dès le moment où une ressource est allouée simultanément à plusieurs projets, si le système de priorisation n’est pas performant, alors des efforts sont en réalité faits sur des projets qui ne les méritent pas et c’est l’ensemble du portefeuille qui en pâtit. Pourtant, que cela est pratique de jouer au petit Salomon et de partager équitablement la ressource ! Les deux chefs de projets sont satisfaits, le comptable divise les heures sur deux postes et le calme revient… mais les deux projets s’en trouvent pénalisés.
Mais alors, comment assurer la pleine utilisation des ressources qui lui sont confiées ?
Monsieur D. comprit que la TOC (Theory of Constraints) allait au-delà de l’optimisation des ressources. La méthode fait fi des habitudes et brise les conventions. On ne s’intéresse pas à l’efficience, on cherche à accélérer les projets, et par là même, à en faire plus avec autant de ressources. Si, pour ce faire, on accepte que le niveau de charge des ressources soit plus faible, et bien soit. En gagnant 25 % sur le délai des projets, on augmente le CA et la marge. Avec de tels chiffres, on accepte de payer pour qu’une ressource ne fasse rien 60 % du temps, mais il faut qu’elle soit disponible à l’instant même où on en a besoin. On perd 40 % d’efficience… mais si l’on commence à utiliser la ressource pour faire autre chose, le risque est grand qu’on perde du délai et donc du CA. Le collaborateur fonctionne comme le bip bip du dessin animé : soit très vite lorsque qu’il est activé, soit pas du tout lorsqu’il n’y a pas de besoin.
La chaîne critique se résume à trois règles, qu’il faut mettre en œuvre en même temps et qui remettent en cause les processus et les organisations internes. Il faut :
Gérer le projet à l’aide d’un buffer, qui absorbe les aléas du projet. Pour ce faire, il faut à la fois travailler sur la durée des tâches élémentaires, au risque de se retrouver avec un planning total significativement plus long que l’initial, mais également remettre en cause la manière de piloter l’avancement du projet. On bascule ainsi d’un suivi à la tâche, ou même sur chacune des tâches (chemin critique ou pas) à un suivi projet via le buffer.
Organiser le lancement de projets en identifiant les ressources contraintes et en cadençant les projets en fonction de ces contraintes. Charger à plus de 100 % une contrainte se traduit par un retard dans les travaux, ou un risque qualité. Cette ressource devient la contrainte du système et pilote le lancement et l’avancement des projets.
Avoir un système de priorités pilotant le portefeuille global de projet. Dans ce cas, le ratio entre la consommation du buffer et l’avancement de la chaîne critique permet de voir les tendances et évite un phénomène classique en début de projet : on commence, mais comme la fin du projet est lointaine, les ressources sont allouées sur d’autres projets plus avancés. Mécaniquement, le ratio se dégrade très rapidement, la priorité du projet augmente et l’on doit rapidement y affecter des ressources. La CCPM (Critical Chain Project Management) cherche à faire avancer globalement le portefeuille de projets, pas à sacrifier un avancement au détriment des autres.
Mais comme souvent, comprendre les règles ne suffit pas. Monsieur D. se met donc à la recherche de personnes, qui, non contentes d’avoir lu le livre, ont mis en œuvre ses principes. La recherche sur internet est frustrante. Les exemples sont souvent les mêmes, comme si chaque auteur reprenait l’exemple du voisin.
Coup de chance, monsieur D. rencontre quelqu’un qui lui présente une entreprise, qui l’avait mis en contact avec le consultant qui les avait aidés à mettre en place la démarche. Il allait enfin comprendre comment mettre en place la CCPM...
Pour plus d'informations, contactez-nous ici ou via l'adresse mail contact@cost-house.com
Commentaires